MobEmu: A Framework to Support Decentralized Ad-Hoc Networking

  • Radu-Ioan Ciobanu
  • Radu-Corneliu Marin
  • Ciprian Dobre
Part of the Studies in Big Data book series (SBD, volume 36)


Opportunistic networks (ONs) are an extension of mobile ad hoc networks where nodes are generally human-carried mobile devices like smartphones and tablets, which do not have a global view of the network. They only possess knowledge from the nodes they encounter, so well-defined paths between a source and a destination do not necessarily exist. There are plenty of real-life uses for ONs, including, but not limited to, disaster management, smart cities, floating content, advertising, crowd management, context-aware platforms, distributed social networks, or data offloading and mobile cloud computing. In order to implement and test a routing or dissemination solution for opportunistic networks, simulators are employed. They have the benefit of allowing developers to analyze and tweak their solutions with reduced costs, before deploying them in a working environment. For this reason, in this chapter we present MobEmu, an opportunistic network simulator which can be used to evaluate a user-created routing or dissemination algorithm on a desired mobility trace or synthetic model.

1 Introduction

In the past years, mobile devices (such as smartphones, tablets, or netbooks) have become almost ubiquitous, which has led to the advent of several new types of mobile networks [1]. Such networks are composed almost entirely of mobile devices, and differ considerably from the classic wired networks, both in terms of structure, but also with regard to the protocols and algorithms used for routing and data dissemination. Since there is no stable topology, nodes in mobile networks are not aware of a global structure and have no knowledge of their relationship with other nodes (like proximity, connection quality, etc.). Each node is only aware of information about the nodes that it is in contact with at a certain moment of time, and may act as data provider, receiver, and transmitter, during the time it spends in the network. Thus, a node can produce data, carry them for other nodes and transmit them, or receive them for its own use.

One type of such mobile networks that have been deeply researched in recent years is represented by opportunistic networks (ONs), which are a form of delay-tolerant networks (DTNs). They have evolved naturally from mobile ad hoc networks (MANETs), which store routing information and update frequently. Opportunistic networks are dynamically built when mobile devices collaborate to form communication paths while users are in close proximity. They are based on a store-carry-and-forward paradigm [2], which means that a node that wants to relay a message begins by storing it, then carries it around the network until the carrier encounters the destination or a node that is more likely to bring the data close to the destination, and then finally forwards it. ONs have also gained popularity because they come as an alternative to using the existing wired infrastructures, which may lead to significant power reduction, as well as the decongestion of said infrastructures.

Figure 1 presents an example of the behavior of an opportunistic network. Let us assume that Alice wants to send a message to Bob (using her smartphone), but she does not have access to a wireless infrastructure. Alice composes the message, which is then stored on her device until a contact opportunity arises. Later, Alice goes for a walk and encounters Chris, who also has a mobile device. The opportunistic algorithm decides that Chris is a good relayer, so it sends him the message for Bob (at time \(t_1\)). Chris will then continue carrying the message until he encounters Daisy (at time \(t_2\)), to whom the message is then relayed further. The cycle can continue on like this, until finally the message arrives at Bob (at time \(t_3\)). Thus, it can be seen that data spreading in opportunistic networks employs a probabilistic approach, since no actual paths exist between nodes, and thus no routing tables are present. When a message is relayed to a node, it is not necessarily deleted from the carrier node, so multiple copies of the same message can exist in the network at the same time. The more copies there are, the higher the chance of the message reaching its destination, but flooding the network with too many messages can easily lead to congestion. Opportunistic algorithms employ various methods for increasing the chances of a successful delivery method, while reducing the latency and the network congestion.
Fig. 1

Opportunistic network interaction

There are several challenges regarding the implementation of opportunistic networking in real-life. One of the main challenges is deciding which nodes should the data be relayed to in order for them to reach their destinations efficiently. Various types of solutions have been proposed, ranging from disseminating the information to every encountered node in an epidemic fashion, to selecting the nodes with the highest social coefficient or centrality. Prediction methods have also been employed, based on the knowledge that the mobile nodes from an opportunistic network are devices belonging to humans, which generally have the same movement and interaction patterns that they follow every day. The analysis of contact time (duration of an encounter between two nodes) and inter-contact time (duration between consecutive contacts of the same two nodes) has also been used in choosing a suitable relay node. Aside from selecting the node that the data will be forwarded to, research has also focused on congestion control, privacy, security, or incentive methods for convincing users to altruistically participate in the network.

Collaboration between mobile devices implies that the messages sent by such a device can successfully reach their destinations. Moreover, even if ONs are delay-tolerant networks, some applications may require data to be delivered quickly, before they become irrelevant. This is why opportunistic network algorithms should strive to achieve high hit rates, together with low delivery latencies. The hit rate signifies the percentage of messages that have successfully reached their intended destinations, while the delivery latency is the time passed between the generation of a message and the time it is received by its destination. In some ON scenarios, such as disaster management, ON users must have a high degree of confidence that the messages sent reach their destinations, because these are potential life-or-death situations. This is the reason why hit rate is often regarded as the most important metric in ONs. However, other side effects of a high hit rate, such as congestion or high resource usage (CPU, battery, etc.) should also be avoided, if possible.

Aside from this, another important limitation of ONs that should be taken into consideration is that nodes do not have a global view of the entire network, since they are dealing with a fully decentralized approach. Therefore, routing or dissemination algorithms are only able to use information collected from encountered nodes, so mechanisms such as gossiping are often employed. An important direction in ON research deals with increasing an opportunistic network’s efficiency, especially with regard to hit rate, delivery latency, and congestion.

Looking at the challenges shown above, it is clear that creating efficient routing and dissemination solutions for ONs is a difficult task. For this reason, frameworks that allow the testing of such solutions before deploying them in real-life are extremely useful. Developers would be able to test their solutions and tweak them in controlled scenarios, being able to change them on the fly, without having to incur high costs (in terms of money and time). However, the challenge in simulating mobile networks arises from two difficult problems: formalizing mobility features and extracting mobility models. Currently, there are two types of mobility models in use: real mobile user traces and synthetic models. Basically, traces are the results of experiments recording the mobility features of users (location, connectivity, etc.), while synthetic models are pure mathematical models which attempt to express the movement of devices. In order to test an opportunistic solution, a simulator that can replay a real-life trace or run a synthetic mobility model, and then apply a given routing or dissemination algorithm, is needed. Thus, our contributions in this chapter are as follows:
  • We perform an analysis of the most important existing synthetic mobility models (in Sect. 2) and real-life traces (in Sect. 3), highlighting their benefits and drawbacks.

  • We present MobEmu, an opportunistic network simulator, which can run a user-created routing or dissemination algorithm on a desired mobility trace or synthetic model (in Sect. 4).

2 Synthetic Mobility Models

As previously stated, the evaluation of opportunistic solutions can be done in two ways. One way of testing an ON is to use mobility models. Several such models were proposed along the years, ranging from basic random models, to map-based or social-based models. In this section, we present the most relevant mobility models, and highlight the benefits and drawbacks of using such models as opposed to mobility traces collected from real-life situations.

2.1 Random Models

One of the first random models was the Random Walk [3], where nodes move by randomly choosing a direction and a speed, then travel for a predefined time t or distance d, after which a new direction and a new speed are randomly chosen. When a border of the simulation area is reached, the node bounces off depending on the angle of its direction, and continues traveling with the selected speed. Multiple versions of the Random Walk model exist, such as 1-D Random Walk, 2-D Random Walk, etc. A random walk on a one or two-dimensional surface returns to the origin with a probability of 1.0, which ensures that the model tests the movements of entities around their starting points.

The Random Waypoint model [4] is very similar to the Random Walk model, except that, after a node finishes traveling (i.e., time t expires or distance d is walked), it pauses for a predefined time period before choosing a new direction and speed. The Random Direction model [5] is also similar, but nodes must travel until the edge of the simulation area before pausing and then choosing a new direction and speed, instead of using the t or d thresholds. This is done in order to decrease the probability of nodes traveling through the center of the simulation area, which is high for the Random Waypoint model.

Other mathematical models are able to control part of the randomness of existing solutions, such as the Boundless Simulation Area model [6], the Gauss-Markov model [7], or the Probabilistic Random Walk model [8] (other similar models are presented in [9]). However, the disadvantage of random models is that they do not have a good similarity to real-life patterns, where users are grouped into communities and social circles. Thus, real users do not move around randomly, but have very specific destinations that are visited regularly. Moreover, the movements in random models are not realistic, since nodes can have any direction, whereas, in reality, human movement follows streets, walkways, buildings, etc.

2.2 Map-Based Models

Map-based models attempt to make node movements more realistic by selecting points on a map as a node’s next position. Thus, for the Random Map-Based model [10], a node’s speed is chosen randomly, while the direction is chosen from a set of allowed directions (i.e., that do not pass through walls, the middle of a street, etc.). A node moves until it encounters a restriction (such as a wall), and then a new direction and speed are generated. For the Shortest Path Map-Based model [11], a correct destination is chosen randomly from the valid positions on the map (or from a list of points of interest, or PoIs), and then a shortest path algorithm such as Dijkstra is employed to compute the path that the node must take until it reaches the destination. Upon doing so (with a randomly-chosen speed), the node computes a new destination and speed, and repeats the previous steps. Finally, the Routed Map-Based model [12] allows nodes to have predefined routes, to mimic real-life movement patterns (such as buses, trams, cars, etc.).

The problem with map-based models is that they are still not realistic enough, and are more useful for vehicular networks than for opportunistic networks. Node movement is not governed by social connections and is basically still random.

2.3 Social-Based Models

Social-based models take into consideration the social aspect of human movement, and one such example is CMM [13], which models the degree of social interaction between two people using a value between 0 and 1, and isolates highly connected sets of nodes into social groups based on their centrality. HCMM, or the Home-Cell Mobility Model [14], takes this approach one step further by assuming that nodes in an opportunistic network are not driven only by the social relationships between them, but also by the attraction of physical locations. Thus, each community has a home cell. This mobility model is based on the caveman model [15] and assumes that each node is attracted to its home cell according to the social attraction exerted on that node by all nodes that are part of its community. According to this model, the attraction of an external cell is computed based on the relationships with nodes that have their home in that cell. When a node reaches a cell that is not its own home community cell, it stays there with a probability \(p_e\), and returns to its home cell with the probability \(1 - p_e\). An HCMM node starts with a preset community, having strong links with the composing nodes. However, based on a rewiring probability \(p_r\), a node’s links can be randomly rewired towards nodes from different communities. Furthermore, a node’s decision to leave its current cell or not is taken based on the remaining probability \(p_{rem}\).

The Working Day model [16] attempts to make node movements more realistic by modeling three major activities that humans perform during a weekday: sleeping (at home), working (at the office), and going out with friends (in a restaurant, in the evening). Depending on the time of day, one of these activities is simulated, by also using three separate transport models. Thus, nodes can move (alone or in groups) by walking, driving, or riding a bus, which increases the heterogeneity of movement. Furthermore, the Working Day mobility model also takes into consideration social relationships and communities, which are composed of nodes that either live together, work in the same office, or go to the same pubs in the evening. The advantage of the Working Day model is that the distributions of contact and inter-contact times are similar to the ones found in real-life traces.

2.4 Discussion

The main advantage of mobility models is that they allow the fine-tuning of many parameters, as opposed to mobility traces, which have coarse temporal or spatial resolution and coverage, while possibly exhibiting bias due to an incorrect choice of participants. Although they have been regarded as suspect models due to the limitations in mapping over reality [17], synthetic models have been largely used in the past. However, Barabási [18] introduced a queuing model which disproved the claims of synthetic models based on random walks on graphs. Furthermore, Barabási’s model showed that the distributions of inter-event times in human activity are far from being normal, as they present bursts and heavy tails. This happens because people do not move randomly, but their behavior is activity-oriented [19, 20, 21]. This endeavor has paved the way for researchers in human dynamics, as the Barabási model [18] is continuously being developed [22, 23, 24, 25], and experiments with it are using a variety of new interesting sources: web server logs, cell phone records, or wireless network user traces.

Thus, we believe that random models should not be employed for opportunistic network testing. Instead, more complex models that take advantage of social information, and that manage to obtain contact and inter-contact time distributions similar to real-life traces should be used. Moreover, we also believe that opportunistic algorithms should also be tested on mobility traces, which is why the MobEmu simulator that we propose and present in Sect. 4 offers support for both mobility models and traces.

3 Mobility Traces

In this section, we address mobility traces, i.e., datasets that are collected after performing a tracing experiment where users carry mobile devices that record their interactions and movement patterns.

3.1 Tracing Experiments

This subsection describes the mobility traces that MobEmu currently supports (i.e., that are implemented in the latest version), including two traces that were performed by us at the University Politehnica of Bucharest (UPB 2011 and UPB 2012). At the end of this section, Table 1 shows details regarding all the presented traces.
Table 1

Mobility traces statistics



Duration (days)


Trace type

Social data

Interest data



St. Andrews





Academic and urban



























Infocom 2006
















UPB 2011








UPB 2012




Bluetooth and Wi-Fi




Sigcomm 2009












Student schedule




























3.1.1 St. Andrews

The St. Andrews trace [26] was collected using a mobile sensor network with Tmote Invent devices carried by 27 participants from the University of St. Andrews: 22 undergraduate students, 3 postgraduate students, and 2 members of the staff. The experiment was performed for a period of 79 days, in which the participants were asked to carry their devices and to keep them on at all times, whether in or out of the town of St. Andrews.

The Invent devices were able to detect and store information about encounters between each other within a radius of 10 m, and were programmed to send discovery beacons at every 6.67 s. The encounter information, comprised of timestamp, and the scanning and detected devices’ IDs, was occasionally uploaded to one of three base stations across the two Computer Science buildings located in the campus of the university. This information was used to create a trace of encounters between Tmotes during the duration of the experiment (the detected social network, or DSN). In addition, a topology (the self-reported social network, or SRSN) was generated using the participants’ Facebook information. The nodes were logically split into three large roles according to the SRSN and four weakly-defined roles according to the DSN.

3.1.2 Haggle Traces

Haggle1 was a European Commission-funded project that designed and developed solutions for opportunistic networks communication, by analyzing all aspects of the main networking functions, such as routing and forwarding, security, data dissemination, and mobility traces and models [27]. The results proposed in Haggle were soon followed by a series of other subsequent research projects targeting similar interests: SCAMPI [28], SOCIALNETS [29], etc. Haggle is today seen by many as the project that created the premises for the advancements on human mobility for information and communications technology-related aspects.

Several mobility traces have been performed in the context of the Haggle project, mostly using Bluetooth-enabled devices such as iMotes. These are mobile devices created by Intel, based on the Zeevo TC2001P SoC, with an ARMv7 CPU and Bluetooth support. Two iMote traces, called Intel and Cambridge, have been presented and analyzed in [30]. The Intel trace was recorded for six days in the Intel Research Cambridge Laboratory, having 17 participants from among the researchers and students at the lab. However, data from only 9 iMotes could be collected properly, since the others had hardware issues. The Cambridge trace was taken for five days, at the Computer Lab of the University of Cambridge, having as participants 18 doctoral students from the System Research Group (out of which 12 devices were used for the final trace). For both traces, the iMotes performed five-second scans at every two minutes, and searched for in-range Bluetooth devices. Each contact was represented by a tuple (MAC address, start time, end time). Internal and external contacts were analyzed, where encounters between two devices participating in the experiment were considered internal contacts, while encounters with other devices were external contacts. The authors analyzed the distribution of contact and inter-contact times, as well as the influence of the time of day on encounter opportunities. Regarding inter-contact time, the traces showed that it exhibits an approximate power law shape, which means that inter-contact distribution is heavy-tailed. The authors showed this observation to hold regardless of the time of day, by splitting a day into three-hour time intervals and noticing that the resulting distributions still maintained power law shapes. Contact durations were also noticed to follow power laws, but with much narrower value ranges and higher coefficients.

In addition to the Intel and Cambridge traces, another trace entitled Infocom was presented and analyzed in [31]. It was collected during the IEEE Infocom conference in Miami in 2005, and had 41 conference attendees as participants, for a total duration of four days. The conclusions were similar to the ones above, namely that the distribution of the inter-contact times between two nodes in an opportunistic network is heavy-tailed over a large range of values, and that it can be approximated to a power law with a less than one coefficient. The authors showed that certain mobility models (such as the Random Waypoint model) do not approximate the real-life traces correctly. Similarly to the Infocom trace, another trace (called Infocom 2006) was performed the following year at the same conference (in Barcelona), but on a larger scale. The Infocom 2006 trace [32] was collected between April 24 and April 26 2006. The nodes in the tracing experiment were also iMote devices given to 78 participants at the student workshop, along with 20 static long-range iMotes deployed throughout the workshop area. Interest information about the nodes was collected through questionnaires given to participants, where they were asked to fill in information such as nationality, school, languages, affiliations, positions, city of residence, and topics of interest selected from among those of the workshop’s CFP. Thus, the trace contains a total of 18 different topics, with an average of 14.53 topics per node.

Finally, the set of Haggle traces also includes Content, which differs from the traces presented so far, since it was not recorded in an academic or conference environment. Instead, it contains sightings recorded in various locations around the city of Cambridge that are likely to be visited by many people, such as grocery stores, pubs, market places, and shopping centers. The participants in the experiment were students from Cambridge University, but also a series of stationary nodes placed in the key places described above. There were 18 such fixed nodes out of a total of 54.

3.1.3 UPB 2011

The UPB 2011 trace [33] is the result of a social tracing experiment that we performed between November and December 2011 at the University Politehnica of Bucharest, which shows not only the interactions of the experiment participants, but also the social relationships they have with each other according to their Facebook profiles. The experiment collected mobility data using an Android application called Social Tracer. The participants were asked to run the application whenever they were in the faculty grounds. Social Tracer sent regular Bluetooth discovery messages at certain intervals, looking for any type of device that had its Bluetooth on. These included the other participants in the experiment, as well as phones, laptops, or other types of mobile devices in range.

When encountering another Bluetooth device, the Social Tracer application logged data containing its address, name, and timestamp. The address and name were used to uniquely identify devices, and the timestamp was used for gathering contact data. Data logged were stored in the device’s memory, therefore every once in a while participants were asked to upload the data collected to a central server located within the faculty premises. All gathered traces were then parsed and merged to obtain a log file. Successive encounters between the same pair of devices within a certain time interval were considered as continuous contacts, also taking into consideration possible loss of packets due to network congestion or low range of Bluetooth. The experiment lasted for a period of 35 days, and involved a total of 22 participants, chosen as statistically varied as possible in order to obtain a good approximation of the mobility aspects of a real academic environment. Thus, there were twelve Bachelor students (one in the first year, nine in the third, and two in the fourth), seven Master students (four in the first year and three in the second), and three research assistants. The participating members were asked to start the application whenever they arrived at the faculty and to turn it off when they left.

It is shown in [33] that the UPB trace follows Hui et al.’s observations [34], namely that the contact and inter-contact times correspond to a power law distribution. It is also shown that the participants have been chosen well so that they represent different groups from the social and logical grouping of nodes in a network based on mobile device carriers in an academic environment. Finally, the k-CLIQUE algorithm [35] has been applied on the trace to show that the local grouping of participants into study years yields similar results to a dynamic grouping such as k-CLIQUE, as well as to the social network organization.

3.1.4 UPB 2012

We collected the UPB 2012 trace [36] at the University Politehnica of Bucharest in the spring of 2012. For this experiment, we implemented an application entitled HYCCUPS Tracer, with the purpose of collecting contextual data from Android smartphones. It was ran in the background and collected availability and mobile interaction information such as usage statistics, user activity, battery statistics, or sensor data, but it also gathered information about a device’s encounters with other nodes or with wireless access points. Encounter collection was performed in two ways, Bluetooth and AllJoyn.2 Bluetooth interaction scanned for paired devices in the immediate vicinity and stored contact information such as the ID of the encountered device and the time and duration of contact. The information stored by AllJoyn tracing was similar, but was collected by constructing and deleting wireless sessions using the AllJoyn framework based on Wi-Fi. The difference between Bluetooth and Wi-Fi is that Wi-Fi consumes more battery life, but is more stable. We observed that AllJoyn interactions occurred much more often than those on Bluetooth. Thus, there were 20,658 Wi-Fi encounters for a total of 66.27% of all the contacts, and only 6969 Bluetooth contacts. We believe that such results were caused by the low range of Bluetooth. Tracing was executed periodically with a predefined timeout for Bluetooth, and asynchronously for AllJoyn interactions.

The duration of the tracing experiment was 64 days, between March and May 2012, and had 66 participants. They were chosen so that they covered as many years as possible from both Bachelor and Master courses. Thus, there were one first-year Bachelor student, one third-year Bachelor student, 53 fourth-year Bachelor students (from five different study directions), three Master students, two faculty members, and six external participants (from an office environment). We were interested only in the participants at the faculty, so we eliminated the external nodes. We also eliminated some nodes that had too little contact information, because they were irrelevant to our experiment. Such nodes belonged to students that did not keep their Android application on at all times when they were at the faculty as they were instructed, or who did not attend many classes in the experiment period. In the end, we remained with 53 nodes with useful information in the trace. By analyzing the participants’ Facebook profiles, we were also able to extract the social connections matrix, as well as the users’ interests. There were five global topics, each participant having in average 3.51 interests.

3.1.5 Other Traces

The Sigcomm 2009 trace [37] was collected using an opportunistic mobile social application entitled MobiClique. The tracing experiment lasted for three days and gathered data from 76 smartphones running MobiClique, which were given to participants of the Sigcomm 2009 conference in Barcelona. When receiving the smartphones, volunteers were asked to fill in their interest data using the MobiClique application, which were then exported anonymously for the trace. There are 151 total topics in the trace, with an average of 15.61 topics per node. NUS [38] is a dataset of contact patterns among students, collected during the spring semester of 2006 at the National University of Singapore, while GeoLife3 is a GPS trajectory dataset collected from 182 users in a period of over three years. SocialBlueConn [39] contains traces of Bluetooth encounters, Facebook friendships, and interests of a set of users, collected through the SocialBlueConn application at University of Calabria and, finally, NCCU [40] contains contact information for a group of college students in a campus environment.

3.2 Discussion

The main reason for developing and using tracing applications such as the ones previously presented (instead of synthetic mobility models) spawns from the need for better mapping onto real-life situations. As previously stated, trace models follow a heavy-tailed distribution with spikes and bursts, making random models obsolete.

The major benefit of tracing applications is the use of a custom data model in order to relate to real situations, real problems, and optimized solutions for said issues. However, this can also lead to a pitfall: if the data model is not correctly designed at the start of the experiment, the entire outcome of the analysis can be biased.

Among the potential challenges of setting up our tracing experiments (UPB 2011 and UPB 2012), we dealt with the following:
  • Finding volunteers representative to our goals was not such an easy task as it may seem. For example, if we would have chosen all participants from the same class, then our results would have been biased because we would have been limiting our targeted scope to a partition of our community graph instead of reaching the entire collective. Moreover, all of the candidates for the experiment needed to have Android devices capable of tracing our data model: Bluetooth connectivity, Wi-Fi connectivity, sensors etc.

  • The design and development of the tracing applications needed to take into account compatibility with multiple types of viable Android devices of varied versions. Furthermore, when developing the tracers, we were obliged to take into account the additional overhead of our applications, as most participants complained about the supplementary power consumption.

  • The installation effort of the tracer was high due to issues such as Bluetooth pairing: all of the participants’ devices needed to pair to each other in order for us to be able to trace their interactions.

  • Last, but not least, we were confronted with the human factor of such experiments: the lack of conscientiousness of our volunteers. Due to the participants not running the tracing application as instructed, the collected data were incomplete. Furthermore, this affected the analysis of said results, as we needed to deploy measures to deal with uncertainty.

In conclusion, we believe that human mobility traces offer a better representation of real-life opportunistic interactions than random synthetic models. However, great care has to be taken when performing the tracing experiments, in order for the collected data to not be biased. Most importantly, the experiment participants should be incentivized to follow the rules of the experiment and carry their mobile devices with the tracing application started whenever it is necessary. Moreover, in order for the collected trace to represent a correct approximation of the entire environment, the participants have to be chosen so that each social community is represented. A caveat of mobility traces is that they generally have a limited time granularity, since scanning for in-range devices is performed periodically, in order to consume less power. Thus, some contacts may be missed, leading to an incomplete trace. Another disadvantage is that the trace results cannot be scaled, since the number of participants is fixed.

As a conclusion, we recommend employing both real-life traces, as well as social-based mobility models, when testing an opportunistic algorithm. For this reason, the MobEmu simulator that we propose and present in Sect. 4 offers support for both.

4 MobEmu

In order to be able to run and test opportunistic networking solutions on mobility traces or models, a simulator for realistic ON evaluation was required. Since the existing solutions did not offer everything we needed (as shown in Sect. 4.5), we implemented MobEmu, an opportunistic framework used for replaying mobility traces and emulating data routing and dissemination algorithms, which we present in this section.

Since opportunistic networks may be composed of hundreds or thousands of devices (if not more), testing new ideas for data routing and dissemination can prove to be a challenge. Furthermore, if the algorithms do not function as expected on the first go, re-deploying a new version would be necessary, which might prove costly, both in terms of money, as well as time and organizational effort. For this reason, simulators are used, which are able to play back existing traces (collected from members of opportunistic networks) or run synthetic mobility models, so that the creator of an algorithm can have an idea regarding how the algorithm behaves prior to actually releasing it in the network.

MobEmu is such a simulator, which can run a user-created algorithm on a desired mobility trace or synthetic model, as long as certain implementation  rules are followed. It is written in Java, so it is highly modular and easy to understand and/or modify, and its source code is freely available on GitHub.4

4.1 Functionality

MobEmu’s functionality is relatively straightforward. It parses a mobility trace and, at every step of the trace (given by the time unit the trace was measured in), it checks whether a contact between two nodes occurs. If this is the case, then the desired routing or dissemination algorithm is applied for each node, in regard to the encountered node. Moreover, various statistics are collected, as will be shown in the next subsection. Aside from checking for contacts, MobEmu checks at every tick whether a node should generate messages for other nodes, an action which is controlled by the user. Thus, the amount of messages sent, their destinations, priorities, number of copies, TTL, etc., can be configured according to each user’s desire. At each step, the emulator also computes a node’s community according to the k-CLIQUE algorithm, as well as its local and global centralities (i.e., inside its community, and outside of it).
Fig. 2

MobEmu components

Regarding the execution of a routing or dissemination algorithm, the user is able to control the data memory size of each node, the amount of history it can store, the speed with which messages can be exchanged, a node’s level of altruism, etc. When a trace run is completed, the desired statistics are printed.

4.2 Components

This subsection presents the main components of MobEmu: the Trace (along with the Parser, Context, and Contact components) and the Node (containing information regarding Altruism, Battery, Messages, Network, etc.). Each of the subcomponents will be described in detail, for a full understanding of MobEmu’s purpose and functionality, and they are also shown in Fig. 2.

4.2.1 Trace

The first step in running an opportunistic algorithm is deciding what type of network it will be run in. As we have previously stated, using mobility traces is a cheaper alternative to deploying and testing an algorithm in a real-life network. MobEmu’s Trace component thus contains a list of Contacts, as well as information regarding the trace’s name. Since all kinds of mobility traces have been collected at faculties or companies all across the Globe, a trace’s sample time may differ, as well as its starting point (for example, some traces start with timestamp 0, while others use the Linux-style epoch). In order to account for such differences, a Trace object also contains information about the trace’s start point, end point, and sample time.

Since we stated that a Trace contains a list of Contacts, it should be noted that such a Contact contains information about the two nodes that are in contact, as well as the starting and finishing time of the contact. Some traces contain contacts collected through various means (such as Bluetooth vs. Wi-Fi), so a Contact also specifies the type of contact between the nodes. The observer and observed nodes are marked separately, because some traces are not symmetrical, i.e., it is possible that a node A sees a node B, but node B does not see node A, because data are collected by polling and the contact is too short for B to start polling again. On the other hand, even if a contact is seen by both nodes, it is highly possible that their clocks are not in sync, or that the polling was performed at different times. However, MobEmu solves this problem by merging contacts between two nodes, as follows: if a node A sees a contact with node B and, while that contact is still ongoing, B sees a contact with A, the second contact is not considered as a separate contact. In conclusion, a Trace contains all the necessary information regarding the contacts between nodes.

MobEmu Trace objects are obtained by running a Parser, which is an interface that contains the following methods: getTraceData (for obtaining the Trace object), getContextData (for getting context information regarding nodes’ preferences), getSocialNetwork (used to obtain the social connections between nodes on online networks such as Facebook or Twitter), and getNodesNumber. The last function returns the number of nodes, but is also useful for knowing the IDs of all the nodes in the trace, since they should be numbered consecutively from 0. The next subsection shows how the Parser interface should be implemented, in order to correctly obtain a trace that can be used in MobEmu.

As stated above, the result of parsing a trace contains not only the Trace object itself, but also a Context map, with a Context object for each node in the trace. A node’s context represents information regarding the node’s interests. Thus, a Context object contains the node’s ID and a set of Topics that the node is interested in. These Topics are represented as integers, and correspond to real-life interests of the user that the opportunistic node belongs to (such as music, movies, books, etc.).

4.2.2 Node

A Node object contains all the information that an opportunistic node requires for running a data routing or dissemination algorithm in MobEmu. Firstly, it contains each node’s ID, which is unique in the network, all nodes being consecutive integers starting from 0.

In order to store messages that are carried opportunistically, a node has a data memory. It contains messages received from other nodes and intended for destinations other than the node itself (since information required by the node is directly sent to the application level, when dealing with data routing). Thus, a node’s data memory is the means through which the store-carry-and-forward paradigm is enforced, along with the routing or dissemination algorithm. The higher a node’s data memory size, the more messages it can carry for other nodes, which offers a great chance of increasing the network’s hit rate. However, having many messages in a data memory leads to longer times required for analyzing the messages and deciding which ones should be forwarded upon an opportunistic contact. Aside from the data memory, a node also has a separate memory where it stores the messages it generates itself. They are kept separate, since they are being handled differently, as a node’s own messages are never deleted from memory. On the other hand, when the data memory is full, some messages may need to be deleted to make room for the new ones. This is implemented using a cache replacement policy.

Both memories (the data memory and a node’s own messages) are represented as lists of Messages. Such an object has a unique ID (to separate between messages more easily), the IDs of the source and destination (or, in case we are dealing with dissemination, the ID of the source and a Context object representing the tags this message is marked with), as well as a timestamp specifying when it was generated. A string for the actual message text is also a part of the Message object. Statistics regarding a message’s path through the network are also kept inside the Message object, in order to make it easier to track. These stats (implemented using a MessageStats object) include whether the message was delivered and to whom, the number of hops the message has traveled, the latency of arriving to the intended destination (or destinations, if performing dissemination), as well as the number of message copies available.

Various opportunistic algorithms need to analyze a node’s memory, in order to decide which messages maximize the overall network hit rate. Thus, MobEmu nodes also contain a map of encountered nodes and information about them, represented as ContactInfo objects. There is such an object for each encountered node, and it specifies the total duration of contacts with that node (i.e., the sum of the durations of all contacts with that node), the number of contacts, and the last encounter time. This information is updated at every contact between two nodes, and may be used for efficient routing or disseminating.

A node also stores statistics about data exchanges that occur at a contact, through an ExchangeStats object, which specifies the time and duration of the last exchange with each encountered node. This is used for aggregating contacts that are seen differently by two nodes (as was described at the beginning of this section). Among other statistics stored by opportunistic network nodes, we would also highlight the number of overflow events (i.e., when the data memory is full and a message is to be received), the total number of messages received, delivered, or exchanged, as well as the number of encounters with every node. The history of data exchanges between nodes is also stored, since it is useful for some algorithms. An ExchangeHistory object is used for this purpose, which stores the timestamp of the exchange, information about the message exchanged (such as source and destination), the nodes that performed the exchange, and the battery level of the forwarding node.

We previously specified that, aside from applying the data routing or dissemination algorithm at each step of the trace, MobEmu also performs community detection using the k-CLIQUE algorithm. This information is stored in a list of node IDs entitled localCommunity. Nodes from this list belong to the current node’s local community, as computed by k-CLIQUE based on the contactThreshold and communityThreshold parameters. As a result of applying k-CLIQUE and detecting communities, each node also has a centrality within that community, as well as a global centrality in the entire network. These values are stored using Centrality objects, since information is required about previous and cumulated values as well. A different type of community, the social network, is also stored as an array of boolean values that specify whether there are friendship relationships between the node and other participants in the network.

Since opportunistic network nodes are generally mobile devices that have limited battery life, it is necessary to be able to model the behavior of the MobEmu nodes as if they were such devices. This is done using a Battery object, which offers information about a node’s current battery level, whether it is recharging or not (and the time left to recharge, if it is), as well as the battery drain model. Consequently, this class contains a method named updateBatteryLevel, called at every step of the trace. This method contains for now a linear formula for draining battery, but this is not necessarily realistic. However, the method can be easily overridden in inherited classes, if a different behavior is expected. A node’s current battery level dictates whether it is actively participating in tracing or not, since a node with a low battery may choose to attempt to maximize whatever is left, and thus avoid acting as a relay for other nodes. This is enforced using a minBatteryThreshold in the Battery object of each node.

As we previously stated, we wish to have a node that behaves as close to real-life as possible. Thus, because opportunistic contacts have limited durations, only a certain amount of data can be exchanged at each contact, so each node should have network information. This is implemented through a Network object that contains the transfer speed of a node, measured in messages per time unit (assuming all messages have the same size). Consequently, depending on the duration of a contact, nodes will only be able to exchange a certain number of messages (we assume that communication is bidirectional, a node’s transfer speed specifying the speed it is receiving data with).

Finally, each node has the context information previously described, represented by a Context object, as well as altruism information in the shape of an Altruism object. Nodes in opportunistic networks may not always act altruistically, for various causes: low level of battery or other resources (CPU, memory, etc.), lack of interest in helping other nodes (such as non-community nodes), etc. Nodes’ refusals to follow the store-carry-and-forward paradigm of opportunistic networks leads to a high decrease of the network hit rate, and an increase of its latency. This not only affects other nodes, but the selfish nodes as well, since they may no longer be helped by nodes that consider them to be selfish. An Altruism object in MobEmu contains the node’s local and global altruism levels, since they can be different based on social or interest communities. For example, a node may only want to relay data for nodes with common interests, or for social neighbors. Perceived altruism values for the other nodes in the network are also stored in the Altruism object (used by selfishness detection and incentive algorithms), as well as a boolean that specifies whether the current node is considered selfish by others or not. When a node is considered selfish, it will not be helped by other devices in the network anymore, so it needs to become more altruistic if it wishes to have its messages delivered.

4.3 Implementing a Mobility Trace Parser

In order to implement a new mobility trace parser in MobEmu, the first step is to implement the Parser interface, which was described above. The four functions previously presented should be implemented: getTraceData should return a Trace object containing the Contacts between the nodes, getContextData should return a map with integer keys (the IDs of the nodes) and Context values (each node’s context, which can even contain no tags, if the node did not specify interests when the trace was collected), getSocialNetwork should return a symmetrical bidimensional array of boolean values (where an entry specifies whether there is a social connection between two nodes), and getNodesNumber should return the total number of nodes in the trace. An important note to be made is that node IDs should be integer values between 0 and \(N-1\) (where N is the value returned by getNodesNumber). Parsers for all the traces shown in Table 1 are implemented in MobEmu.

Aside from working with mobility traces, MobEmu can also replay data generated by a mobility model, and the functionality is exactly the same as when replaying a trace. The movement and interaction data are generated by the model and stored as Contact objects in a Trace, and then the next steps are exactly the same as when dealing with traces. The only difference is that the parameters of mobility models can be configured, ranging from number of nodes to the size of the network. MobEmu currently supports the HCMM model presented in Sect. 2.

4.4 Implementing a Routing or Dissemination Algorithm

The most important step in implementing an opportunistic routing or dissemination algorithm in MobEmu is writing the data exchange function. However, prior to presenting how this is done, we start by describing the steps taken by the emulator when two nodes are in contact.

When two MobEmu nodes meet opportunistically (based on the data contained in the trace), the exchangeData function is called by the observer node. This function receives the observed node as a parameter, as well as the duration of the contact and the current trace time. If a contact between the two nodes is already in progress (caused, as specified before, by the differences in clocks or sampling intervals of the nodes), then the function simply returns. However, if the contact just began, the onDataExchange function is called. This is an abstract function that should be implemented by any class that extends Node. All such classes implement the actual dissemination or routing algorithm through the onDataExchange function, while at the same having access to all the information of the current node (which is why we decided to use inheritance, rather than composition).
Fig. 3

Steps for implementing a routing or dissemination solution

Thus, all that is required for writing a routing or dissemination algorithm is implementing the onDataExchange function, but there are several guidelines that should be followed, as shown in Fig. 3. Firstly, since the first parameter of the onDataExchange function is of type Node, it should be checked if it is indeed an instance of the implementing class, and cast to it. Then, the next step is generally to perform the delivery of direct messages, which are messages destined for the current node (when dealing with routing) or marked with tags that the node is interested in (if disseminating data). This is done by calling the deliverDirectMessages method. Then, the messages from an encountered node’s data memory and own memory (i.e., the messages it generated itself) are analyzed and, based on an algorithm-specific decision, they are downloaded by the current node or not. A message is downloaded by calling the insertMessage function at the current node. If the network bandwidth is considered restricted, then the user must ensure that more messages than allowed per contact are not downloaded. Altruism can also be taken into account when performing data exchanges upon a contact, but it is the programmer’s job to decide whether a node is selfish or not, and whether it should not be helped by other nodes.

Statistics are collected automatically, so the user does not need to do this explicitly, unless more stats are needed. For this, new fields should be added to the Node implementation, and they should be updated when necessary, by extending the corresponding functions. Furthermore, the statistics are aggregated by using the Stats class, which should be extended, and methods for various statistics should be added as desired.

A user may also wish to change the way messages are generated. Currently, this is done daily, in a time interval around lunch (since this is generally when the most contacts occur for the majority of the traces). If the current algorithm performs point-to-point routing, then messages are generated by default using a Zipf distribution with exponent 1, where the most messages are sent to nodes that are both in a node’s community, as well as in its online social network, and the fewest to nodes that have no connection to the current node. If dissemination is performed, a node chooses a random interest, and generates a message marked with it. The generateMessages function from the Message class can be overridden if a new message generation behavior is desired. The opportunistic routing or dissemination solutions currently implemented in MobEmu are briefly described in the following subsections.

4.4.1 Epidemic

The Epidemic algorithm [41] is based on the way a virus spreads: when two potential carriers meet, the one with the virus infects the other one, if it is not already infected. Thus, when an ON node A encounters a node B, it downloads all the messages from B that it does not already contain, and vice versa. The simplest version of this algorithm assumes that a node’s data memory is unlimited, so that it can store all the messages that can be at once in the opportunistic network.

However, this is unfeasible in real-life, especially as the network grows larger, so a modified Epidemic version is also implemented in MobEmu, where the data memory of a node is limited. Thus, when node A’s memory is full and it encounters node B, first it has to drop the oldest messages in its memory, in order to make room for the new messages that it will download from node B. This also makes the algorithm somewhat inefficient, since some older messages may be important (e.g., they may be addressed to nodes that A is about to encounter), while some new ones may be totally irrelevant (e.g., their destinations may be nodes that A will never meet). Furthermore, Epidemic nodes perform many data exchanges, especially in large networks with highly mobile nodes, so the problem of congestion can arise. This can happen not only in the network, but also at each individual node, especially if the network is dense. Performing data exchanges often can also very easily deplete a node’s battery, since opportunistic networks are mainly composed of small mobile devices such as smartphones, with limited lifetimes.

4.4.2 BUBBLE Rap

BUBBLE Rap [32] is a routing algorithm for opportunistic networks that uses knowledge about nodes’ communities to deliver messages. It assumes that a mobile device carrier’s role in the society is also true in the network, thus the first part of the algorithm is to forward data to nodes that are more popular than the current node. The second assumption made by BUBBLE Rap is that the communities people form in their social lives are also observed in the network layer, therefore the second part of the algorithm is to identify the members of the destination community and pass them the relevant messages. Thus, a message is bubbled up the hierarchical ranking tree using a global popularity level, until it reaches a node that is in the same community as the destination. Then, the message is bubbled up using a local ranking until it reaches its target. The popularity of a node is given by its betweenness centrality, which is the number of times a node is on the shortest path between two other nodes in the network. Community detection is done using k-CLIQUE, while the centralities are computed by replaying the last collected mobility trace, applying a flooding algorithm, and then computing the number of times a node acts as a relay on a shortest path.

However, this implementation of BUBBLE Rap is unfeasible in real-life, because it has to know the behavior of the nodes beforehand. Therefore, a distributed version entitled DiBuBB is also proposed by the authors [32]. It uses distributed k-CLIQUE for community detection, together with a cumulative or single window algorithm for distributed centrality computation. The single window (S-window) algorithm computes centrality as the number of encounters the current node has had in the last time window (chosen usually to be six hours), while the cumulative window (C-window) algorithm counts the number of individual nodes encountered for each time window, and then performs an exponential smoothing on the cumulated values.

4.4.3 ML-SOR

Whereas solutions like BUBBLE Rap only employ social network information, ML-SOR (Multi-Layer SOcial network-based Routing) [42] also uses interest information, as well as encounter history. Thus, it exploits three social network layers: the online social network, the interest network, and the contact network. The latter is the proximity graph created through contacts between devices, while the online social network is extracted from virtual contacts. Thus, a layer is represented as a weighted graph, where the edges are social links between the nodes, which are the vertices. A tuple of multiple such social network layers is defined as a multi-layer social network.

ML-SOR extracts social network information from multiple contexts and analyzes encountered nodes in terms of node centrality, tie strength, and link prediction, on different social network layers. When an ML-SOR node A encounters a node B, it computes a social metric called MLS for all the messages in B’s memory, both from its own standpoint, as well as from B’s. If MLS is higher for node A in terms of a message M, then A sends a download request for M. The social metric is computed based on three components: CS, TSS, and LPS. CS represents the centrality of the nodes in the contact history graph, while TSS and LPS are computed with regard to the message’s destination. TSS is the online social network strength between the analyzed node and the destination, and LPS is a link predictor computed on an interest network layer. It counts the number of common interests between the encountered node and the message’s destination.

Thus, the ML-SOR algorithm tries to forward messages to nodes that are more important than the carrier node on three levels. An important node is defined as a node with a high centrality (i.e., with many encounters), which is connected to the destination on the online social network, and has multiple interests in common with the destination. ML-SOR is therefore based on the assumptions that nodes that are socially connected tend to meet each other more often, and so do nodes with common interests.

4.4.4 Moghadam-Schulzrinne

The dissemination solution proposed by Moghadam and Schulzrinne [43] uses interest information when distributing data. This interest-aware algorithm is able to analyze a user’s history of cached data in order to obtain his interests. Using these interests, the algorithm is able to decide whether a document carried by an encountered node should be downloaded or not when a contact occurs. Interests are represented as vectors of interest, which are obtained by applying extended latent semantic analysis and singular value decomposition on the documents that have been viewed or cached on each user’s device. When a node A meets a node B, the former has to decide which documents should be forwarded to the latter. This is done by mapping each document carried by A into B’s interest space and applying cosine similarity. If the result is higher than a predefined threshold, then that document is transferred to B.

Thus, documents are only spread to nodes that are interested in their content, which in turn can forward them further on to nodes with similar interests. By using such an algorithm, the number of data exchanges in the network decreases dramatically, since a node can only carry a document that it is interested in (and that the nodes it will encounter are, with a high probability, interested in too). The results show that the interest-based algorithm is able to deliver 30% more relevant documents and 35% fewer irrelevant documents, when compared to Epidemic routing.

4.4.5 Social Trust

Social Trust [44] is a trust method that leverages social information to establish trustworthy communication for mobile opportunistic networks. Nodes’ trust is social-based, since it is argued that they belong to an opportunistic network composed of people’s devices (such as smartphones). Thus, socially-connected nodes have an intrinsic trust in each other, since they are likely to interact more often in good conditions.

The authors propose employing two major techniques of establishing trust: Relay-to-Relay and Source-to-Relay. When using the former method, a node that is carrying a message computes the trust in an encountered peer based on the relationship between the two nodes, while the latter method assumes that candidate relays are analyzed based on their relationship with the message’s source. For each of the two trust methods, four ways of computing a node’s trust are proposed (and implemented in MobEmu): common interests, common friends, social graph distance, and a combination between common friends and social distance. These filters are based on research in the area of human mobility, which shows that socially-connected people are more likely to encounter each other than to have contacts with stranger nodes. The same goes for interests: people with common interests tend to meet often and on a regular basis. Since opportunistic network nodes are very likely humans carrying mobile devices, it is natural to employ knowledge about human mobility and interactions.

4.4.6 JDER

JDER [45] is an opportunistic routing solution that is based on the idea that there are circumstances when information about social connections is not available, or the social network is much too large to be used efficiently. In such situations, socially-aware algorithms do not behave efficiently, since they are mostly focused on forwarding messages to popular nodes that are likely to communicate with many other nodes in the network. However, there are critical nodes (cut nodes) with less apparent popularity that play an important role in the dissemination process of messages in the network, so they have to be found and selected as forwarders in order to guarantee a high delivery ratio.

The JDER algorithm attempts to find the cut nodes by employing two metrics: the history encountered ratio and the Jaccard distance. The former specifies how often each encountered node has been met, whereas the latter is a measure of similarity, and is computed as the number of common neighbors between two nodes. Thus, if two peers are similar according to the Jaccard distance, then they need to exchange data. Similarly, if an encountered node is similar to the destination of a message, that message must be transferred to the encountered node, which has a high chance of encountering the destination.


IRONMAN [46] is a selfish node detection and incentive mechanism for opportunistic networks that uses pre-existing social information to detect and punish selfish nodes, incentivizing them to participate in the network. Each IRONMAN node stores a perceived altruism (or trust) value for other nodes, that is initialized based on the social network layout: if the nodes are socially connected, this value is higher than for non-community nodes. When a node A meets a node B, it checks its encounter history to see if B has ever created a message for A that has been relayed to another node C. If this is the case, and A has encountered C after B had given it the message but A did not receive the message, then C is considered selfish, and A’s perceived altruism of C is decreased. Whenever a node A receives a message from a node B which is not the source of the message, A’s perceived altruism of B is increased.

Apart from detecting selfish nodes, IRONMAN also uses incentives to make nodes behave better. Therefore, whenever a node B is considered selfish by A (its perceived altruism is below a given threshold), it is notified, and A will not accept any messages from it (but will keep on forwarding its own messages to B). Therefore, a selfish node might end up not being able to send its messages, unless it becomes altruistic. IRONMAN uses perceived altruism ratings for encountered nodes, in order to decide if they are selfish or not. These ratings are computed locally based on the analysis of the history of contacts whenever two nodes meet, but the local values are exchanged with other nodes at every encounter, in order to inform them if a node is selfish.

4.4.8 SENSE

SENSE [47] is a novel social-based collaborative content and context-based selfish node detection algorithm with an incentive mechanism, which aims to reduce the issues caused by having selfish nodes in an ON. It uses gossiping and context information to make informed decisions regarding the altruism of nodes in the network, on one hand, and incentive mechanisms to make selfish nodes become altruistic, on the other. SENSE takes advantage of social relationship knowledge regarding the nodes in the ON, to decide if a node is selfish towards its own community.

When a SENSE node A encounters another peer B, A verifies B’s reputation before deciding to employ it as a relay. This reputation is computed based on past information regarding B’s behavior, obtained not only from A’s observations, but also through gossiping from the other nodes in the network. If node A decides that B is altruistic, then it continues to communicate with it normally. However, if node B is considered selfish, then A will not only stop sending its messages to B (i.e., it will not use it as a relay), but it will not help B deliver its messages. Thus, node B will be forced to become unselfish if it wants its messages delivered. The SENSE algorithm uses social information for differentiating between community altruism and selfishness, while also taking into account other context information such as battery level.

4.4.9 SPRINT

SPRINT [48, 49] is a data routing algorithm for opportunistic networks that uses social information and contact prediction to perform forwarding decisions. More specifically, upon a contact between two nodes in an ON, it employs a utility function for computing the value of each message carried by the two nodes. The goal is for each node to maximize the utility of the messages it is carrying, through data exchanges. Thus, each node computes the utility of every message, and then stores the N most valuable ones (where N is the maximum number of messages that a node can transport).

The utility function has two components, the first of them taking into account a message’s freshness (i.e., how much time has passed since it has been generated), as well as the probability that the current node is able to bring the message closer to its intended destination. This probability is computed by analyzing a node’s contact history and its social connections, and by using a Poisson distribution. The second component of the utility function is based on a node’s social connection with the message’s destination, the number of hops that the message has traveled through, the node’s popularity, and the time spent by the node in contact with the message’s destination.

MobEmu also supports a version of SPRINT entitled SPRINT-SELF [50], which contains SENSE mechanisms for trust and reputation when performing opportunistic routing, as well as incentivizing nodes to participate in the ON.

4.4.10 ONSIDE

ONSIDE [51, 52] is an algorithm that not only uses interest knowledge for opportunistic data dissemination, but also social information about the nodes in the network, in an attempt to decrease an ON’s overall bandwidth consumption and reduce its congestion, while not affecting the average per-topic hit rate and the delivery latency.

The ONSIDE algorithm is based on several assumptions, one of them being that nodes with common interests tend to meet each other more often than nodes without. The second assumption that ONSIDE is based on states that connections from online social networks (such as Facebook, Google+, or LinkedIn) are respected in an ON node’s encounters. Whenever two nodes running ONSIDE meet, they exchange lists of messages in their data memory and lists of topics each node is interested in. Based on this information, each node analyzes the other node’s messages and decides which of them should be downloaded. This decision is firstly based on common interests between the encountering nodes, so that data transfers are only performed between nodes with at least one common interest. The second component of the decision function ensures that a node will not only download a message for itself and then drop it after use, but will also store it for others, since it is highly likely to encounter other nodes that have interests similar to its own. The data exchange decision is also based on the idea that a node encounters its social connections often, so, if it has friends interested in a message it encounters, it should download that message in order to ensure a quick delivery. The last component of the exchange function is computed based on the nodes’ encounter history, assuming that a node’s behavior in an ON is predictable, so that if it encountered many nodes subscribed to a certain topic, it is likely to encounter others in the future as well.

The ONSIDE implementation from MobEmu also contains mechanisms for sorting the messages in a node’s memory, in order to ensure that, when a node’s memory is full and it has to download a new message, it will drop the least significant one that it has stored (instead of the oldest one, as per the default case). Furthermore, the MobEmu implementation of ONSIDE also contains SENSE mechanisms for trust management and incentives.

4.4.11 Interest Spaces

Interest Spaces [53] is a context-adaptive and knowledge-based middleware for mobile collaborative systems. Its purpose is to offer a unified framework for data dissemination in ONs, providing mobile applications with a message exchange mechanism in networks where Wi-Fi access points or mobile broadband connections are not available, or an alternative is needed. MobEmu has implementations for its dissemination and reputation components.

A node’s interest in the Interest Spaces framework is expressed as a tag, and there are three types of nodes: publishers, subscribers, and cache nodes. The former are nodes that can publish data. In order to do so, they must specify tags for the data objects they publish. Other nodes that are subscribed to those tags are able to receive messages generated by the publishers. Subscribers are nodes that are interested by information marked with certain tags. They are able to specify the tags they are interested in at any time, as well as to unsubscribe from them. Messages that subscribers are interested in should arrive as fast as possible, especially in environments where data can become stale quickly. Finally, the cache nodes represent the backbone of the Interest Spaces framework, in the sense that they perform the actual heavy lifting. Their task is to cache and transport data items for the benefit of others. Nodes are able to become cache nodes for certain tags when they are in the vicinity of other nodes interested in such tags, or when they are known to interact often with said nodes. They store data of interest to these nodes until they encounter them and deliver the data. A node is a cache node for a certain context, which is computed on the fly and can change very quickly.

The cache decision function is based on the idea that a node that sees a certain tag often (i.e., it encounters nodes that carry messages marked with that tag or that are interested in that tag) would be a good cache node for messages marked with that particular tag. Furthermore, this decision also takes into account the social connections between nodes. The trust and reputation component of Interest Spaces, entitled SAROS [54], is based on node gossiping for building trust in the other peers in the opportunistic network. Furthermore, messages that reach an interested node are not directly delivered to the application level. Instead, multiple copies of the same message (delivered on different routes by different nodes) are compared, and a quorum algorithm is used for selecting the valid version. This way, malicious nodes that alter messages can be detected, and the other nodes in the network are notified to avoid them.

4.5 Related Work

The most well-known simulator for opportunistic networks is ONE (Opportunistic Network Environment) [12]. It is a Java application that simulates various ON scenarios, allowing the customization of node behavior in terms of contacts, routing algorithms, transfer speed, battery, etc. The main functions of the ONE simulator are the modeling of node movement, inter-node contacts, routing, and message handling. Result collection and analysis are done through visualization, reports, and post-processing tools.

Each ONE node is represented by a main module which can connect to other submodules that represent its capabilities, such as radio interface, persistent storage, movement, energy consumption, or message routing. Transfer speed is abstracted to a communication range and bit-rate, which are statically configured and remain constant over the simulation. The node energy consumption model is based on an energy budget approach, where each node starts with a given energy level, which decreases when certain activities (such as data transmission) are performed.

Regarding node interactions, several approaches can be taken by a ONE simulation, similarly to MobEmu. Synthetic movement models can be employed, which include random movement models (such as Random Walk and Random Waypoint), map-constrained models (Random Map-Based Movement, Shortest Path Map-Based Movement, and Routed Map-Based Movement), as well as human behavior-based movement models (such as the Working Day Movement model presented in Sect. 2). Moreover, real-world traces such as the ones presented in Sect. 3 can be imported into the ONE simulator.

Messages are generated either randomly, or with a fixed source, destination, size, and interval. One main drawback of the ONE simulator is that all messages are unicast and directed, so they have a specific destination, which does not allow for data dissemination without further tweaking of the implementation.

There are six routing protocols included in the simulator, which can be run on a mobility model or a trace: direct delivery, first contact, Spray-and-Wait [55], PROPHET [56], MaxProp [57], and Epidemic [41]. However, new protocols can be added to ONE by extending a class (called ActiveRouter) and implementing specific methods.

The ONE simulator offers a Graphical User Interface (GUI) for visualizing the simulation live (showing the positions of nodes in the simulation space, their interactions, etc.), while statistics are also collected and exported in log files. Simulation scenarios can be built by defining the ON participants and their capabilities (such as storage capacity, transmission range and bit-rates, movement models, routing algorithms, etc.), as well as global parameters (such as duration, time granularity, etc.), through simple text-based configuration files. This offers less experienced users an easy way of creating and testing various scenarios.

The main caveat of ONE (and the reason we implemented MobEmu) is that it does not work for data dissemination out of the box. As stated before, messages can only be directed towards a single destination, so a publish/subscribe-based solution cannot be tested. Moreover, it does not offer support for community detection, social network knowledge, altruism modeling, or context data (i.e., topics of interest). Since we needed these components for implementing our routing and dissemination solutions, as well as our context-adaptive and knowledge-based middleware for mobile collaborative systems (Interest Spaces), we decided to implement our own ON simulator (MobEmu). We believe that not only does it offer more capabilities than the ONE simulator, but it is easier to maintain and extend, due to the simplicity and modularity of the code.

Other simulators that offer support for opportunistic networks include ns-2,5 ns-3,6 DTN2,7 OMNet++,8 or GloMoSim [58], but they have either been discontinued, are not used on a large scale, or do not offer complete support for ON simulations.

5 Conclusions

In this chapter, we have introduced the notions of mobility traces and synthetic models, highlighting the benefits and drawbacks for each of them. We argued that, when implementing an opportunistic routing or dissemination solution, it should be tested both using a social-based synthetic model, as well as on multiple mobility traces that cover as many real-life scenarios as possible.

In order to be able to do this, we presented MobEmu, an opportunistic network simulator that is able to run a mobility model or replay a trace, while applying the desired routing or dissemination algorithm. It is a Java application that offers simplicity and modularity, while at the same time allowing more experienced users a deep control over the scenarios they want to test. We showed that other similar simulators do not have all the capabilities that MobEmu offers, so its implementation was necessary.




This chapter is based upon work from COST Action IC1406 High-Performance Modelling and Simulation for Big Data Applications (cHiPSet), supported by COST (European Cooperation in Science and Technology).

The research presented is also supported by national projects DataWay (PN-II-RU-TE-2014-4-2731) and MobiWay (PN-II-PT-PCCA-2013-4-0321).


  1. 1.
    Ciobanu, R.-I., Cristea, V., Dobre, C., Pop, F.: Big Data Platforms for the Internet of Things, pp. 3–34. Springer International Publishing, Cham, (2014)Google Scholar
  2. 2.
    Pelusi, L., Passarella, A., Conti, M.: Opportunistic networking: data forwarding in disconnected mobile ad hoc networks. Comm. Mag. 44(11), 134–141 (2006)CrossRefGoogle Scholar
  3. 3.
    Gerl, Peter: Random walks on graphs. In: Heyer, Herbert (ed.) Probability Measures on Groups VIII. Lecture Notes in Mathematics, vol. 1210, pp. 285–303. Springer, Berlin Heidelberg (1986)CrossRefGoogle Scholar
  4. 4.
    Johnson, D.B., Maltz, D.A.: Dynamic Source Routing in Ad Hoc Wireless Networks. In: Imielinski and Korth, (eds.) Mobile Computing, vol. 353. Kluwer Academic Publishers, (1996)Google Scholar
  5. 5.
    Nain, P., Towsley, D., Liu, B., Liu, Z.: Properties of random direction models. In: INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE, vol. 3, pp. 1897–1907. March 2005Google Scholar
  6. 6.
    Haas, Z.J.: A new routing protocol for the reconfigurable wireless networks. In: Universal Personal Communications Record, 1997. Conference Record., 1997 IEEE 6th International Conference on, vol. 2, pp. 562–566. (Oct 1997)Google Scholar
  7. 7.
    Liang, B., Haas, Z.J.: Predictive distance-based mobility management for multidimensional pcs networks. IEEE/ACM Trans. Netw. 11(5), 718–732 (2003)CrossRefGoogle Scholar
  8. 8.
    Chiang, C.-C., Gerla, M.: On-demand multicast in mobile wireless networks. Proc. IEEE ICNP 98, 14–16 (1998)Google Scholar
  9. 9.
    Camp, T., Boleng, J., Davies, V.: A survey of mobility models for ad hoc network research. Wireless Commun. Mobile Computing 2(5), 483–502 (2002)CrossRefGoogle Scholar
  10. 10.
    Derrida, B., Flyvbjerg, H.: The random map model: a disordered model with deterministic dynamics. J. de Phys. 48(6), 971–978 (1987)MathSciNetCrossRefGoogle Scholar
  11. 11.
    Soares, V.N.G.J., Rodrigues, J.J.P.C., Farahmand, F.: Impact Analysis of the Shortest Path Movement Model on Routing Strategies for VDTNs in a Rural Region. In: Proceedings of 7th Conference on Telecommunications, CONFTELE 2009Google Scholar
  12. 12.
    Keränen, A., Ott, J., Kärkkäinen, T.: The ONE Simulator for DTN Protocol Evaluation. In: Proceedings of the 2Nd International Conference on Simulation Tools and Techniques, Simutools ’09, pp. 55:1–55:10, ICST, Brussels, Belgium, Belgium, 2009. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering)Google Scholar
  13. 13.
    Musolesi, M., Mascolo, C.: Designing mobility models based on social network theory. SIGMOBILE Mob. Comput. Commun. Rev. 11(3), 59–70 (2007)CrossRefGoogle Scholar
  14. 14.
    Boldrini, C., Passarella, A.: HCMM: modelling spatial and temporal properties of human mobility driven by users’ social relationships. Comput. Commun. 33(9), 1056–1074 (2010)CrossRefGoogle Scholar
  15. 15.
    Watts, D.J.: Small Worlds: The Dynamics of Networks Between Order and Randomness. Princeton University Press, Princeton, NJ, USA (2003)zbMATHGoogle Scholar
  16. 16.
    Ekman, F, Keränen, A., Karvo, J., Ott, J.: Working day movement model. In: Proceedings of the 1st ACM SIGMOBILE Workshop on Mobility Models, MobilityModels ’08, 33–40, New York, NY, USA, 2008. ACMGoogle Scholar
  17. 17.
    Musolesi, M., Mascolo, C.: Mobility Models for Systems Evaluation. In: Garbinato, C., Miranda, H., Rodrigues, L. (eds.) Middleware for Network Eccentric and Mobile Applications, chap. 3, pp. 43–62. Springer Berlin Heidelberg, Berlin, Heidelberg, 2009Google Scholar
  18. 18.
    Barabasi, A.L.: The origin of bursts and heavy tails in human dynamics. Nature 435(7039), 207–211 (2005)CrossRefGoogle Scholar
  19. 19.
    Doci, A., Barolli, L., Xhafa, F.: Recent advances on the simulation models for Ad hoc networks: real traffic and mobility models. Scalable Computing: Practice and Experience, 10(1), (2009)Google Scholar
  20. 20.
    Doci, A., Springer, W., Xhafa, F.: Impact of the Dynamic Membership in the Connectivity Graph of the Wireless Ad hoc Networks. Scalable Computing: Practice and Experience, 10(1), 2009Google Scholar
  21. 21.
    Hummel, K.A., Hess, A.: Movement activity estimation for opportunistic networking based on urban mobility traces. In: Wireless Days (WD), 2010 IFIP, 1–5, Oct. 2010Google Scholar
  22. 22.
    Oliveira, J.G., Barabási, A.L.: Human dynamics: darwin and Einstein correspondence patterns. Nature 437(7063), 1251 (2005)CrossRefGoogle Scholar
  23. 23.
    Hidalgo R, C.A.: Conditions for the emergence of scaling in the inter-event time of uncorrelated and seasonal systems. Phys A: Stat. Mech. Its Appl. 369(2), 877–883 (2006)CrossRefGoogle Scholar
  24. 24.
    Vázquez, A.: Exact results for the Barabási model of human dynamics. Phys. Rev. Lett. 95(24), 248701+ (2005)CrossRefGoogle Scholar
  25. 25.
    Vázquez, A., Oliveira, J.G., Dezsö, Z., Goh, K.-I., Kondor, I., Barabási, A.-L.: Modeling bursts and heavy tails in human dynamics. Phys. Rev. E. 73(3), 036127+ (2006)CrossRefGoogle Scholar
  26. 26.
    Bigwood, G., Rehunathan, D., Bateman, M., Henderson, T., Bhatti. S.: Exploiting self-reported social networks for routing in ubiquitous computing environments. In: Proceedings of the 2008 IEEE International Conference on Wireless & Mobile Computing, Networking & Communication, WIMOB ’08, pp. 484–489, Washington, DC, USA, 2008. IEEE Computer SocietyGoogle Scholar
  27. 27.
    Su, J., Scott, J., Hui, P., Crowcroft, J., De Lara, E., Diot, C., Goel, A., Lim, M.H., Upton, E.: Haggle: Seamless Networking for Mobile Applications. In: Proceedings of the 9th International Conference on Ubiquitous Computing, UbiComp ’07, 391–408. Springer. Berlin, Heidelberg, 2007Google Scholar
  28. 28.
    Pitkänen, M., Kärkkäinen, T., Ott, J., Conti, M., Passarella, A., Giordano, S., Puccinelli, D., Legendre, F., Trifunovic, S., Hummel, K., May, M., Hegde, N., Spyropoulos, T.: SCAMPI: service platform for social aware mobile and pervasive computing. SIGCOMM Comput. Commun. Rev. 42(4), 503–508 (2012)CrossRefGoogle Scholar
  29. 29.
    Allen, S.M., Conti, M., Crowcroft, J., Dunbar, R., Lió, P.P.., Mendes, J.F., Molva, R., Passarella, A., Stavrakakis, I., Whitaker, R.M.: Social Networking for Pervasive Adaptation. In: Self-Adaptive and Self-Organizing Systems Workshops, 2008. SASOW 2008. Second IEEE International Conference on, pp. 49–54, (Oct. 2008)Google Scholar
  30. 30.
    Chaintreau, A., Hui, P.: Pocket Switched Networks: Real-world mobility and its consequences for opportunistic forwarding. Technical report, 2006 Computer Laboratory, University of Cambridge, February 2005Google Scholar
  31. 31.
    Chaintreau, A., Hui, P., Crowcroft, J., Diot, C., Gass, R., Scott, J.: Impact of human mobility on opportunistic forwarding algorithms. IEEE Trans. Mob. Comput. 6(6), 606–620 (2007)CrossRefGoogle Scholar
  32. 32.
    Hui, P., Crowcroft, J., Yoneki, E.: BUBBLE Rap: social-based forwarding in delay tolerant networks. In: Proceedings of the 9th ACM International Symposium on Mobile Ad Hoc Networking and Computing, MobiHoc ’08, 241–250, New York, USA, 2008. ACMGoogle Scholar
  33. 33.
    Ciobanu, R.I.: Ciprian Dobre, and Valentin Cristea. Social aspects to support opportunistic networks in an academic environment. In: Proceedings of the 11th International Conference on Ad-hoc, Mobile, and Wireless Networks, ADHOC-NOW’12, 69–82. Springer, Berlin, Heidelberg (2012)Google Scholar
  34. 34.
    Hui, P., Chaintreau, A., Scott, J., Gass, R., Crowcroft, J., Diot, C.: Pocket switched networks and human mobility in conference environments. In: Proceedings of the 2005 ACM SIGCOMM Workshop on Delay-Tolerant Networking, WDTN ’05, 244–251, New York, NY, USA, 2005. ACMGoogle Scholar
  35. 35.
    Hui, P., Yoneki, E., Chan, S.Y., Crowcroft, J.: Distributed community detection in delay tolerant networks. In: Proc. of 2nd ACM/IEEE inter. workshop on Mobility in the evolving internet architecture, MobiArch ’07, 7:1–7:8, New York, NY, USA, 2007. ACMGoogle Scholar
  36. 36.
    Marin, R.-C., Dobre, C., Xhafa, F.: Exploring Predictability in Mobile Interaction. In: Emerging Intelligent Data and Web Technologies (EIDWT), 2012 Third International Conference on, 133–139. IEEE, 2012Google Scholar
  37. 37.
    Pietiläinen, A.-K., Oliver, E., LeBrun, J., Varghese, G., Diot, C: Mobiclique: Middleware for mobile social networking. In: Proceedings of the 2Nd ACM Workshop on Online Social Networks, WOSN ’09, 49–54, New York, NY, USA, 2009. ACMGoogle Scholar
  38. 38.
    Srinivasan, V., Motani, M., Ooi, W.T.: Analysis and Implications of Student Contact Patterns Derived from Campus Schedules. In: Proceedings of the 12th Annual International Conference on Mobile Computing and Networking, MobiCom ’06, 86–97, New York, NY, USA, 2006. ACMGoogle Scholar
  39. 39.
    Socievole, A., De Rango, F., Caputo, A.: Wireless contacts, Facebook friendships and interests: analysis of a multi-layer social network in an academic environment. In: Wireless Days (WD), 2014 IFIP, 1–7. IEEE, November 2014Google Scholar
  40. 40.
    Tsai, T.-C., Chan, H.-H.: NCCU Trace: social-network-aware mobility trace. Commun. Mag. IEEE 53(10), 144–149 (2015)CrossRefGoogle Scholar
  41. 41.
    Vahdat A., Becker, D.: Epidemic routing for partially-connected ad hoc networks. Technical report, Duke University, April 2000Google Scholar
  42. 42.
    Socievole, A., Yoneki, E., De Rango, F., Crowcroft, J.: Opportunistic message routing using multi-layer social networks. In: Proceedings of the 2Nd ACM Workshop on High Performance Mobile Opportunistic Systems, HP-MOSys ’13, 39–46, New York, NY, USA, 2013. ACMGoogle Scholar
  43. 43.
    Moghadam A., Schulzrinne, H.: Interest-aware content distribution protocol for mobile disruption-tolerant networks. In: World of Wireless, Mobile and Multimedia Networks Workshops, 2009. WoWMoM 2009. IEEE International Symposium on a, 1–7, June 2009Google Scholar
  44. 44.
    Mtibaa A., Harras K.A.: Social-based trust in mobile opportunistic networks. In: 2011 Proceedings of 20th International Conference on Computer Communications and Networks (ICCCN), 1–6, July 2011Google Scholar
  45. 45.
    Ciobanu, R.I., Dobre, C., Toral, S.L., Johnson, P.: Jder: A history-based forwarding scheme for delay tolerant networks using jaccard distance and encountered ration. J. Netw. Comput. Appl. Daniel Gutierrez Reina 40, 279–291 (2014)CrossRefGoogle Scholar
  46. 46.
    Bigwood, G., Henderson, T.: Ironman: Using social networks to add incentives and reputation to opportunistic networks. In: SocialCom/PASSAT, pp. 65–72. IEEE, (2011)Google Scholar
  47. 47.
    Ciobanu, R.-I., Dobre, C., Dascălu, M., Trăuşan-Matu, Ş., Cristea, V.: SENSE: a collaborative selfish node detection and incentive mechanism for opportunistic networks. J. Network Computer Appl. 41, 240–249 (2014)CrossRefGoogle Scholar
  48. 48.
    Ciobanu, R.I., Dobre, C., Cristea, V.: Reducing congestion for routing algorithms in opportunistic networks with socially-aware node behavior prediction. In: Proceedings of the 2013 IEEE 27th International Conference on Advanced Information Networking and Applications, AINA ’13, 554–561. IEEE Computer Society, Washington, DC, USA (2013)Google Scholar
  49. 49.
    Ciobanu, R.I. Dobre, C., Cristea, V: SPRINT: Social prediction-based opportunistic routing. In: 2013 IEEE 14th International Symposium and Workshops on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), 1–7 June 2013Google Scholar
  50. 50.
    Ciobanu, R.I., Dobre, C., Cristea, V., Pop, F., Xhafa, F.: SPRINT-SELF: social-based routing and selfish node detection in opportunistic networks. Mobile Inf. Sys. 1–12, 2015 (2015)Google Scholar
  51. 51.
    Ciobanu, R.-I., Marin, R.-C., Dobre, C., Cristea, V.: Interest-awareness in data dissemination for opportunistic networks. Ad Hoc Networks 25(PB), 330–345 (2015)CrossRefGoogle Scholar
  52. 52.
    Ciobanu, R.-I., Marin, R.-C., Dobre, C., Cristea, V., Mavromoustakis, C.X.: ONSIDE: socially-aware and interest-based dissemination in opportunistic networks. In: Network Operations and Management Symposium (NOMS), 2014 IEEE, 1–6 May 2014Google Scholar
  53. 53.
    Ciobanu, R.-I., Marin, R.-C., Dobre, C., Pop, F.: Interest spaces: a unified interest-based dissemination framework for opportunistic networks. J. Syst. Architec. 72, 108–119 (2017)CrossRefGoogle Scholar
  54. 54.
    Ciobanu, R.-I., Marin, R.-C., Dobre, C., Cristea, V.: Trust and reputation management for opportunistic dissemination. Pervasive Mob. Comput. 36, 44–56 (2007). (Special Issue on Pervasive Social Computing)CrossRefGoogle Scholar
  55. 55.
    Spyropoulos, T., Psounis, K., Raghavendra, C.S.: Spray and wait: an efficient routing scheme for intermittently connected mobile networks. In: Proceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking, WDTN ’05, 252–259, New York, NY, USA, 2005. ACMGoogle Scholar
  56. 56.
    Lindgren, A., Doria, A., Schelén, O.: Probabilistic routing in intermittently connected networks. SIGMOBILE Mobile Computing Commun. Rev. 7(3), 19–20 (2003)CrossRefGoogle Scholar
  57. 57.
    Burgess, J., Gallagher, B., Jensen, D., Levine B.N.: Maxprop: Routing for vehicle-based disruption-tolerant networks. In: INFOCOM 2006. 25th IEEE International Conference on Computer Communications. Proceedings, 1–11, April 2006Google Scholar
  58. 58.
    Zeng, X., Bagrodia, R., Gerla, M.: GloMoSim: a library for parallel simulation of large-scale wireless networks. SIGSIM Simul. Dig. 28(1), 154–161 (1998)CrossRefGoogle Scholar

Copyright information

© Springer International Publishing AG 2018

Authors and Affiliations

  • Radu-Ioan Ciobanu
    • 1
  • Radu-Corneliu Marin
    • 1
  • Ciprian Dobre
    • 1
  1. 1.University Politehnica of BucharestBucharestRomania

Personalised recommendations