Functionality and components
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. 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, or outside of it).
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.
There are two 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.), as shown in the figure.
The first step in running a mobility algorithm is deciding what type of network it will be run in. 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.
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. WiFi), 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 is 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.
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. Later on you will see an example of how the Parser interface should be implemented, in order to correctly obtain a trace that can be used in MobEmu.
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.).
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 data 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. 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.
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.
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. 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. 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.