A context-rich and extensible framework for spontaneous smartphone networking

Computer Communications 37 (2014) 25–39

Contents lists available at ScienceDirect

Computer Communications journal homepage: www.elsevier.com/locate/comcom

A context-rich and extensible framework for spontaneous smartphone networking Elmurod Talipov, Jianxiong Yin, Yohan Chon, Hojung Cha ⇑ Department of Computer Science, Yonsei University, Seodaemun-gu, Shinchon-dong 134, Seoul 120-749, Republic of Korea

a r t i c l e

i n f o

Article history: Received 24 December 2012 Received in revised form 30 September 2013 Accepted 13 October 2013 Available online 24 October 2013 Keywords: Spontaneous networking Context learning Delay-tolerant applications Content sharing

a b s t r a c t This paper presents the design principles, implementation, and evaluation of SPONET, a framework that has been specifically developed for spontaneous networking among smartphone users. SPONET has four distinct objectives, providing (1) a rich context for location-aware networking, (2) robust cognitive networking, (3) extensibility with various routing protocols, and (4) a convenient programming interface for delay-tolerant applications. The key technical challenges are, therefore, unsupervised place learning, network construction without user intervention, and a networking policy with low complexity. We have designed a place-learning algorithm using the properties of scanned Wi-Fi access points to identify meaningful places. SPONET provides dynamic neighbor discovery and data exchange mechanisms for autonomous networking. We have implemented SPONET on Android-based, off-the-shelf smartphones without any adaptation of their networking architecture. Experimental results show that the proposed system is indeed acceptable as a framework for various delay-tolerant applications in smartphones. Ó 2013 Elsevier B.V. All rights reserved.

1. Introduction With the current proliferation of mobile devices, spontaneous interaction between colocated devices that do not acknowledge each other a priori will become commonplace. Among mobile devices, smartphones are rapidly growing in number, and the administration effort of handling the traffic generated by smartphones is also increasing. At the same time, cellular network operators are deploying more and more Wi-Fi access points (APs) to offload traffic from cellular networks to wired networks. However, the operators are well aware that this is not a permanent solution, and alternative solutions are being sought. One approach lies in using spontaneous opportunistic networking. Unlike traditional ad hoc networks, spontaneous networking is an application-oriented approach with the following advantages: (1) It overcomes the limitations of communication services built upon the widely used concept of end-to-end connectivity, and (2) it works in a plug-and-play manner, minimizing the effort required to integrate devices and services into network environments. In the literature [1–3], spontaneous networks have been referred to as pocket-switched networks (PSNs), delay- or disruption-tolerant networks (DTNs), and opportunistic networks (ONs), to name a few. In this paper, we refer to these networks as spontaneous smartphone networks

⇑ Corresponding author. Tel.: +82 2 2123 5711; fax: +82 2 365 2579. E-mail address: [email protected] (H. Cha). 0140-3664/$ - see front matter Ó 2013 Elsevier B.V. All rights reserved. http://dx.doi.org/10.1016/j.comcom.2013.10.004

(SSNs) in order to elaborate target networks. SSNs specifically assume the existence of unique constraints, such as the availability of localization techniques, motion sensors, various radio interfaces, and regularities in the movements of smartphone users. The opportunistic network research community believes that many applications would benefit from the implementation of opportunistic network frameworks. Lindgren et al. [4] have presented a number of such applications, such as telemedicine for developing regions that would allow doctors to remotely give correct diagnoses and prescribe treatment [5], unrestricted communication in the presence of oppressive governments [6], file sharing and bulk data transfer, and automatically synchronizing mobile and static devices. In particular, bulk data sharing and automatic content synchronizing benefit from the implementation of SSNs as smartphone users generate massive amounts of content each a day and intend to share and synchronize it with others or with other personal digital devices. Efforts in the field of designing and implementing SSN-like networks are generally classified into two groups: special purpose implementations [7–11] and generic implementations [12–15]. While generic implementations can be used by various applications on many different devices, special purpose implementations are targeted to specific applications or devices. Although some of these implementations [7,9,11,12] have shown good performance in terms of data delivery, the systems are neither efficient in networking nor instantly usable on smartphones. This is because these systems do not satisfy at least one of the requirements [4] listed below.

26

E. Talipov et al. / Computer Communications 37 (2014) 25–39

First, the system should be context aware, meaning that human dynamics should be considered and networking tasks should be conducted intelligently. In other words, the places where users often visit should be identified, and user mobility needs to be predicted to reduce communication overhead. Second, implementation must overcome technological constraints and should be instantly usable on smartphones. The current level of technology poses a number of constraints in terms of ad hoc networking. Such constraints are the connection-oriented nature of Bluetooth radio, the Wi-Fi ad hoc mode not being supported, the limited battery capacity of mobile devices, and the diversity of mobile devices. For instance, devices that use Bluetooth radio should be pre-paired. Although the Wi-Fi ad hoc mode is supported by many smartphones, the functionality is normally not enabled due to the power issue. But despite the existence of these limitations, previous implementations have required Wi-Fi ad hoc mode support or used Bluetooth communication. Third, extensibility and multiple application support must be available. The system should support various routing mechanisms and message management methods, and it should provide rich APIs to enable diverse applications. Finally, users are always concerned about their battery life and are often concerned about privacy issues regarding their locations and social contexts. Hence, the system ought to be energy and resource efficient and must protect the privacy of users. In this paper, we present the design principles and implementation of a context-rich, flexible spontaneous networking framework called SPONET. The design challenges of SPONET have been unsupervised place learning and an autonomous networking policy with low complexity. SPONET overcomes the aforementioned challenges and provides the following contributions:  SPONET autonomously identifies and remembers users’ mobility behavior and social relationships for context-aware networking.  A spontaneous networking mechanism analogous to Wi-Fi Direct [16] has been designed to quickly discover neighboring devices and exchange bulk data. The key advantage is that the scheme does not require modification to the software architecture of mobile devices. Also, user intervention is avoided in device pairing.  SPONET is extensible with various routing mechanisms and supports diverse DTN applications. The remainder of the paper is organized as follows. Section 3 presents a brief overview of the system. Section 4 describes the context-generation method, and Section 5 covers the details of spontaneous networking and integration into the proposed system. In Section 6, we discuss implementation challenges, programming interfaces, and case study application. System evaluation in terms of complexity, context-generation accuracy, and networking efficiency is presented in Section 7. We discuss relevant work and limitations of our system in Section 8, and conclude the paper in Section 8

2. The SPONET architecture SPONET is a context-aware, spontaneous networking framework. Here, context-awareness means the system can generate various types of user information and devices states, and spontaneous networking means an autonomous peer-to-peer communication and data delivery. Hence, SPONET can largely be divided into two functionalities: context generation and spontaneous networking. The system is designed to provide a context-rich, efficient networking environment for delay-tolerant, peer-to-peer applications. We have implemented SPONET on Android phones using the

available programming interfaces and built-in sensors such as an accelerometer, electronic compass, GPS, Wi-Fi, and GSM. Fig. 1 shows the overview of the SPONET system, which consists of eight key components: the activity manager, landmark manager, context manager, link-state manager (LSM), neighbor manager (NM), message manager (MM), routing protocol adaptor (RPA), and context provider. We have assumed that bulk data are usually exchanged in places where smartphone users stay for a significant amount of time. Consequently, the system tracks a user’s movements and identifies places where the user stays for a significant duration. The activity manager monitors user activity and schedules other system tasks. The component continuously checks the variance of the accelerometer signal and the phone state to identify user activity, which is classified as either ‘‘moving’’ or ‘‘stationary.’’. The landmark manager discovers and learns landmark information, which is comprised of both physical and logical location information. The landmark in short is a place where user stays longer than a certain duration. The component obtains the physical location information from the GPS provider and the network provider. Each provider generates location information along with an error bound that reflects the accuracy of the location estimation. The providers are readily implemented into the Android protocol stack and can be invoked using special APIs. The logical provider determines the logical identification of a landmark and decides if the current location is a landmark that the user has previously visited. In parallel to context generation, the LSM discovers neighboring smartphones and creates a spontaneous network. The NM collects neighbor information and neighbor encounter information and hands it over to the context manager. The NM also monitors active neighbors and assists routing protocols for data exchange. The MM and RPA are the core components for spontaneous networking. The MM receives application data and schedules it for delivery to the destination. Additionally, the messages processed by the RPA are handed to the MM and delivered to applications. The RPA contains a number of prebuilt DTN routing protocols, and based on current routing protocols, this component makes the decisions regarding message forwarding. Additionally, the RPA provides an interface for adding new routing protocols. Finally, the context provider is responsible for managing storage, such as aggregating raw data into refined data and removing expired message information. This component also manages the database to provide data to the internal user interface and other applications. When a stationary activity is detected, the system runs two tasks. First, the context manager generates the user context from the landmark manager and activity manager. Then, the LSM initiates neighbor discovery and creates a spontaneous network. The NM collects neighbor information and posts it to the context manager as additional context. The system immediately deactivates each sensor after obtaining the necessary context information. The relationship between a user’s activity and a set of components is predefined to minimize energy consumption. Fig. 2 illustrates the activity-based decision flow used to dynamically provide context-aware networking. In the following section, we will describe how each component is used to construct a complete spontaneous networking system.

3. Context generation Context generation is the process of collecting and updating the user’s context. We formally define context as processed data on a landmark, user activity at the landmark, neighbors, and neighbor encounters associated with the landmark. Generated context is stored in the database via the context provider. We are only interested in collecting context when a user is stationary. Thus, we

E. Talipov et al. / Computer Communications 37 (2014) 25–39

27

Fig. 1. SPONET system overview.

Fig. 2. SPONET decision flow; the activity manager processes the signal read from the accelerometer and separates tasks into two subflows based on classified activity: (1) context generation, network initiation, and message handling, and (2) context update, and networking termination; T STA is the stationary duration and T MOV is the moving duration; the default thresholds of d ¼ 5 min and n ¼ 2 min are used to identify whether the user is continuously staying (CS) or continuously moving (CM).

continuously monitor the signal change of the accelerometer and generate a context when a user stays in a place for a significant duration. A detailed description of context generation is given in the following subsections. 3.1. Activity monitoring The activity monitoring task is executed by the activity manager of SPONET. The input of the activity manager is an acceleration vector of a 3-axis accelerometer, and the output is the classification of user activity. User activity is classified as either moving or stationary. While a user is walking, running, or moving

in a vehicle, the motion is classified as moving; otherwise, the motion is stationary. Making a decision from a single accelerometer reading is usually biased [17]. Consequently, a number of samples from the accelerometer are read, and the variance of the samples is computed. If the variance is greater than the predefined threshold (e.g., 0:24 m2 =s4 ), the activity is classified as moving. Otherwise, the user is assumed to be in stationary mode. When the activity manager continuously observes a user as being in stationary mode, it initiates two tasks: context generation and network initiation. For context generation, the context manager obtains location information from the landmark manager and creates a new context or

28

E. Talipov et al. / Computer Communications 37 (2014) 25–39

updates the old context in the database via the content provider. Once the network is initiated by the LSM, the NM collects information on neighboring smartphones. Activity monitoring also initiates network termination and a context update when moving activity is observed, after a user stays at a location for a significant duration. The following sections describe how these tasks are carried out. 3.2. Landmark learning The key element of context is a landmark, which is a location that a user often visits and stays at for a significant duration. Using knowledge of these landmarks, context-aware networking can be efficiently put in place. For example, we can predict the sequence of landmarks the user will visit and accordingly estimate future communication opportunities. In SPONET, a landmark consists of physical and logical location information and is generated by the landmark manager. The landmark manager obtains physical location information from the GPS provider and network provider as a form of latitude, longitude, and an error bound. The error bound shows the location accuracy, and the location with the smallest error bound is selected. However, physical location is insufficient to distinguish between different landmarks. Both the GPS provider and network provider often give different latitude and longitude for the same landmark. In addition, landmarks that have the same latitude and longitude but are on different levels cannot be distinguished. In order to correctly identify landmarks, we use logical location information that contains the location area code (LAC), basic service-set identifier (BSSID), the received signal strength indicator (RSSI) of nearby Wi-Fi APs, and a unique landmark identifier (ULID). The LAC is a unique number that is obtained from a cellular network. Both BSSID are RSSI are obtained by scanning neighboring APs, and the ULID is generated at the time of landmark creation. We have employed the place-matching algorithms mentioned in [17,18] to identify a new landmark. The algorithm first extracts all landmarks that have the same LAC as the landmark. In the absence of an LAC, the landmarks within the error bound of the current landmark are extracted. The tuple of extracted landmarks is denoted as L ¼ L1 ; L2 ; . . . ; Ln , and the Wi-Fi vector at landmark Li !

is denoted as W ¼ w1 ; w2 ; . . . ; wm . Each member of the vector wi Li

contains Wi-Fi AP’s BSSID and signal strength information. For   two landmarks Li and Lj , the similarity function C Li ; Lj is defined using the Tanimoto coefficient [19]:





C Li ; Lj ¼

8 > < different > :

!

if

i

2

j

!

!

!

kW L k þkW L k2 W L W L i

same

!

W L W L !

j

i

j

6u

;

ð1Þ

else

where u is the similarity threshold. We have empirically determined that when the similarity threshold is set to 0.5, any place within an average office is identified as the same landmark. In many cases, exchanging a landmark or sequence of landmarks between smartphones is necessary in order to provide a location-based service or to route content efficiently. Exchanging the entire physical and logical location information of landmarks poses disadvantages. For instance, exchanging physical location information is invasive in terms of privacy. Also, the amount of logical location information increases in proportion to the number of Wi-Fi APs and landmarks. Therefore, we generate a ULID for each landmark, and the identity of a landmark is only known to a user who has visited the landmark. The pseudo-code for ULID generation is shown in Algorithm 1. In this algorithm, the k strongest APs in terms of the RSSI are selected, and two variables, u and o, are computed by performing the ‘‘and’’ and ‘‘or’’ operation within

their BSSIDs. Then, concatenation of LAC, u, and ois hashed using the secure hashing algorithm 1 (SHA1) [20]. The result is a double-hashed unique identifier within the LAC, and the LAC is unique within the network. Algorithm 1. Generating the ULID for Landmarks Input: LAC A, Wi-Fi set W ¼ hW 1 ; W 2 ; . . . ; W m i, k Output: Unique Landmark Identifier (ULID) Notation: = {b,r}, b is BSSID, r is RSSI 1: 2: 3: 4: 5: 6: 7: 8: 9:

W.sort()// sort by RSSI r. u=W 1 .b; o = W 1 . b n = min (k, W. size) for i = 2 to n u = u & W i. b o = o jW i . b end for U = concatenate (A, u, o) return SHA1 (U)

3.3. Landmark prediction Predicting the landmarks that the user may visit in the future is necessary for optimized sensor scheduling [21], resource provisioning [22], and routing protocols [3]. The analysis in [23] suggests that using an order-2 Markov predictor has high accuracy and that it is appropriate for use with resource-constrained devices. The order-2 Markov predictor estimates the next landmark using the two most recently visited landmarks. Hence, given the visited landmarks Lt1 and Lt , the transition probability to future landmark Ltþ1 is expressed as:

PðLt ; Ltþ1 Þ ¼ PðX tþ1 ¼ Ltþ1 jX t1 ¼ Lt1 ; X t ¼ Lt Þ:

ð2Þ

In SPONET, the content provider stores the transition edges between landmarks; hence, the transition probability between all landmark pairs is estimated in a single search from the edge of the table without extra computation overheads. Then, the location with the highest transition probability is chosen as the next landmark. If the order-2 Markov predictor fails to estimate the future landmark, we use the result of the order-1 predictor [23]. Thus, the landmark that is most visited at t þ 1 in the past is selected as the predicted landmark. Based on the information collected at the predicted landmark, which includes duration of stay, we can predict the next delay (u) period. As we have shown in Fig. 2, the next delay (u) is used to avoid unnecessary sensor reading. Hence, u can be estimated as follows:

u¼

P

k DT k

M

;

ð3Þ

where DT k is the kth stay duration at the predicted landmark Ltþ1 and M is the number of stays at the landmark. 4. Spontaneous networking Connecting smartphones over wireless links involves steps that usually annoy users. For example, using Bluetooth for communication requires pairing up devices beforehand or modifying the software stack to avoid the steps. Other methods, such as IEEE802.11s, mesh networking and the ad hoc mode [24] are not fully supported by manufacturers and are not implemented on smartphones. To eliminate user involvement in configuring the communication, we have designed a spontaneous networking method analogous to Wi-Fi Direct [16]. Wi-Fi Direct enables peer-to-peer

E. Talipov et al. / Computer Communications 37 (2014) 25–39

communication without joining a traditional home, office, or hotspot network. In spontaneous networking, smartphones act either as a SPONET provider (SP) or SPONET client (SC). The SP is an ‘‘AP-like’’ entity that provides BSS functionality and services for associated SCs. SCs are wireless stations that provide Wi-Fi simple configuration (WSC) enrollee [16] functionality and that communicate with each other via an SP. Additionally, legacy clients may also join the spontaneous network, but the provided services of SPONET are limited. In short, an SP and SCs construct a star topology to communicate with each other. Communication in spontaneous networks is initiated when a node arrives at a landmark and goes through the following phases. First, the node forms a spontaneous network group with colocated nodes or joins an existing spontaneous group. Second, the NM discovers neighboring nodes, and the LSM establishes virtual links. Then, the actual communication session is managed by the MM and RPA. Finally, when the node is about to depart, the NM informs neighboring nodes, and the LSM disconnects the links. 4.1. Link-state management LSM is the process of establishing and controlling virtual communication links between nodes. Establishing communication links between moving nodes is neither energy efficient nor stable for bulk data exchange. The activity manager, therefore, only triggers the LSM when a node arrives at a landmark or starts moving away from a landmark. Upon landmark arrival, the LSM obtains the list of discovered Wi-Fi APs from the context manager and searches for available SPs. SPs are usually identified with a special SSID. If the node finds an existing SP, it connects to the SP using the Wi-Fi Simple Configuration (WSC) method. When the node does not find an SP, it switches on softwarebased AP (Soft-AP) functionality and serves as an SP. In short, we simulate a wireless local area network on an SP by using Soft-AP functionality so that other nodes are able to connect to it. When the node serves as an SP, other nodes that arrive at this landmark connect to this node, and neighbor discovery is performed. The limitation of the Soft-AP functionality, which is the main difference from Wi-Fi Direct, is that the device which has switched to the Soft-AP mode cannot connect to a traditional Wi-Fi access point (unless the device changes its state to the Wi-Fi device mode). On the other hand, Wi-Fi Direct provides a simultaneous connection to another Wi-Fi Direct device or access point. However, not all the smartphones are equipped the Wi-Fi Direct-enabled network interface. While a node remains stationary, the LSM becomes idle and waits for a trigger from the activity manager. The LSM notifies the NM about the possible link disconnection upon the detection of movement. The NM broadcasts leave a message, and the connection is terminated. When the leaving node is an SC, then the node does nothing more than the basic action mentioned above. However, when an SP is leaving, one of the remaining nodes forms a new spontaneous network group. In order to avoid multiple SPs leaving a network group, we use a semi-randomized waiting time. A node k waits for the duration of Dt k after receiving the leave message, performs a Wi-Fi scan, and serves as the SP unless another SP is found. We compute Dtk using the following equation:

Dt k ¼ wðZmod xÞ þ rand ½0; w;

ð4Þ

where w is the average time required for configuration, Z is the last byte of the IP address obtained from the previous SP, and x is the maximum possible number of SCs per SP. We have empirically found that w is 5 s and x is 8 s. Although the last byte of a node’s IP address Z is unique, modulating it by xis not absolutely unique. However, with an additional random delay between 0 and w, the

29

conflict is reduced since each node performs a scan before forming a new group. Conflict in forming a new group may also occur when two nodes arrive at a landmark at a similar time. To cover such cases, Z is set to the mobile equipment’s identification number because nodes do not have an IP address. Since the number of SCs per SP is limited, the number of nodes in the same landmark might be greater than the possible SCs per SP. In such cases, multiple spontaneous groups should be formed. To identify such cases, we use the DHCP refuse packets sent by the SP. When a client receives the packet, the node organizes a new spontaneous group. Nodes in two or more spontaneous groups switch connection from one group to another when content distribution is necessary.

4.2. Neighbor discovery and management The neighbor-discovery process collects social context by detecting neighbors within the communication range. Neighbor discovery is a challenging issue for current smartphones since the radio interface of Wi-Fi devices in standard mode only listens to packets from APs due to power and CPU usage considerations. Therefore, we have used a passive form of the dynamic neighbor discovery mechanism, what we call the blind date model. In this model, just as when two people become known to each other after a meeting, nodes can discover each other only if they are at the same landmark and are able to send and receive beacon messages. In SPONET, the NM discovers/manages neighbors and acts upon the trigger of the LSM. When a node joins a network group or forms a new group, the NM periodically sends beacon messages. We have used the user-datagram protocol (UDP) broadcast method to deliver beacon messages. At the same time, the NM runs a UDP listener thread, which listens to the SPONET discovery port. Beacon transmission and reception is synchronized, and they operate with a certain duty-cycle ratio. With the reception of beacon messages, the NM creates a new entry in the neighbor table or updates the entry of an existing neighbor. The neighbor table holds the neighbor identifier, connection status, local IPv4 address, and last contact time. The neighbor identifier is a 128-bit unique number generated by hashing the international mobile equipment identifier (IMEI) with the MD5 hashing algorithm [25]. Hashing the IMEI removes vulnerability to security threats. The connection status indicates if the node is currently connected to a spontaneous network group, and it is set to ‘‘connected’’ upon receiving beacons. The last contact time is the time of beacon reception. When the connection status is ‘‘connected,’’ the MM and RPA perform a message exchange. Finally, when a node is leaving the landmark, it broadcasts a leave message. Other members of a network group then set the connection status of a corresponding neighbor entry to ‘‘disconnected.’’ In some cases, the leave message might not be delivered due to the disconnected link. For such cases, we use the following technique to detect lost neighbors. Nodes, as a rule, receive beacons from other nodes with a certain interval, d. For each neighbor, with a periodicity u that is larger than d, the NM checks its lost neighbor by calculating the difference s between current time and last contact time. If s is larger than d, it means the neighbor has left. The connection status of lost neighbors is changed to ‘‘disconnected.’’ Fig. 3 shows the process of LSM and neighbor discovery. In addition to neighbor discovery and management, the NM is also responsible for generating context on neighbors. The NM inserts and updates neighbor information in the database via the context provider. Also, it computes the contact time, rate, and duration with neighbors, associates them with landmarks, and stores this in the database.

30

E. Talipov et al. / Computer Communications 37 (2014) 25–39

Fig. 3. Link-state management and neighbor discovery; the delay times DtA and DtB are computed using Eq. 4.

4.3. Adaptive duty cycling Continuous accelerometer reading and UDP listening consumes high amounts of energy. In order to reduce the energy consumption of sensors, we have applied an adaptive duty cycling policy. The policy is mainly based on the efficient sensor scheduling discussed in Section 3.1. First, the accelerometer reading is scheduled based on the prediction of arrival or departure time to landmarks. Then, upon the detection of moving activity, UDP listening is terminated until it is retriggered by the activity manager. Continuous stationary activity is detected when a user sojourns in a landmark. UDP listening is then scheduled with a certain duty cycle ratio. The ratio is adaptively calculated depending on the predicted sojourn time and the number of neighbors the user encounters in the detected landmark. Thus, the UDP listening cycles between sleep and listen states. The length of the sleep state is defined based on the predicted encounter time of neighbors. If the user has not encountered other users in the past, we may use the Additive Increase Multiplicative Decrease method for calculating the length of the sleep state, which is defined as follows:

( wtþ1 ¼

wt þ a if neihgbor is not detected wt b

else

;

ð5Þ

where wt is waiting duration until the next listen state at time t, and

a and b are constants. These values are used to adjust the waiting duration between two consecutive beacon messages. In this case, the value of a is equal to the time instance (i.e., the duration) and it is inferred from the threshold duration d for identifying meaningful places as mentioned in Fig. 2. The value of b is proportional to the number of neighbors and it is adaptively changed with the discovery of new neighbors. The reason behind this policy is that when the neighbor is detected, the data exchange should be periodically scheduled and neighboring devices need to discover each other more frequently. In case the user has encountered other users in the current landmark, UDP listening operates with a fixed duty cycle ratio, which can be defined by network administrators. 4.4. Message management and content synchronization The message management and content synchronization tasks are fulfilled by the MM; this includes handling, dispatching, and scheduling messages. In a content synchronization task, the MM processes content from applications and delivers it to its destination. The messages are classified into two groups: (1) control messages distributed via the UDP interface, and (2) content messages that flow through the transmission control protocol (TCP) connection.

Now, we explain the general dispatching routines of the messages. Control messages trigger the components of the SPONET framework. There are four types of control messages in SPONET: neighbor-beacon messages, neighbor-leave messages, contentadvertisement messages, and content-request messages. The MM dispatches the messages by type. Neighbor-related messages (i.e., beacon and leave) are handed to the NM and are further processed there. Content-related messages (i.e., content advertisement and content request) are forwarded to the RPA, and the header of the RPA is extracted. The RPA header is comprised of a routing protocol identifier and routing header. The routing protocol identifier for both external and internal routing protocols is assigned by the RPA during SPONET initialization. According to the routing protocol identifier, the relevant routing protocol processes the routing header and makes a decision to either discard the advertisement message or to request actual content for this advertisement. The decision is returned to the MM, where a content request is sent to the content advertiser over the UDP. The content request contains a content identifier and a specific TCP port to receive the message. The content identifier is a unique number assigned by the content source and included in the advertisement. The content advertiser then binds the connection using a TCP port and transfers the actual content. This data-exchange method is important for antiharassment, meaning that malicious users can not directly flood data to others. Content is usually requested in two cases: (1) The receiving node is the content destination or (2) the receiving node can relay the content to the destination. Fig. 4 illustrates the concise description of the message handling and synchronization process. The content message is either directly handed to a relevant application or queued for forward opportunities after being stored. Content, which is destined for the receiver, is transferred to the application layer; otherwise, it goes into storage (e.g., an SD card). The MM has an interface to receive content messages from the application layer. When the MM receives a content message, it searches for the destination of the message in an active-neighbor list. If the destination node is found, the MM binds TCP communication with the destination and immediately transfers the message. Otherwise, the MM creates a new entry in the message table for this message. The message table is part of the database and has the following fields: message (content) identifier, application port, delivery deadline, and link to the actual data in storage. The elements of the message header for content are restricted to these fields of the message table. With careful consideration in terms of utilizing local storage, the MM’s scheduler unit periodically checks the message table to remove messages with expired deadlines. When a node encounters other nodes, the scheduler prepares messages for delivery. The scheduler is also linked with the storage manager of the context

E. Talipov et al. / Computer Communications 37 (2014) 25–39

31

Fig. 4. Message handling and synchronization; the dash-dotted lines represent the UDP broadcast, the dashed lines represent the UDP unicast, and the solid lines represent TCP communication.

provider to apply message-dropping algorithms. If the data for storage is more than the storage quota defined by the user, the scheduler drops some messages based on algorithms, such as ‘‘drop the oldest first’’ or ‘‘drop the message with lowest delivery probability’’ [27]. 4.5. Routing protocol adaptation Another key functionality of SPONET is extensibility with various routing protocols. SPONET only supports delay-tolerant and opportunistic routing protocols, which do not assume the existence of end-to-end connectivity. Key functions of the DTN routing protocol are to make a decisions regarding forwarding messages and selecting the next hop node. In SPONET, each routing protocol registers three callback functions — forward/receive decision maker, relay selector, and header generator. Also, external routing protocols can use the local context access APIs to obtain other information. For example, they can access the encounter rate between nodes (i.e., the number of encounters per time unit), current activity, movement probability (i.e., probability of movement from one location to another), time to next landmark, etc. In order to differentiate between routing protocols, SPONET assigns a unique identifier analogous to the TCP/UDP port for each routing protocol. Each routing protocol determines its own routing header, which is not limited to a specific format. The RPA obtains routing headers using the registered header generator callback of the routing protocol. The routing protocol identifier and routing header together comprise the RPA header, which was mentioned in the previous section. The RPA header is attached to content advertisement and content request messages following the SPONET header. The RPA headers are generated by the source of content or by the request-generating node. Intermediate nodes that receive the RPA headers extract the routing header and forward it to the decision-maker callback of the relevant routing protocol. The decision-maker function extracts elements of the header and returns a decision on receiving actual content. As we mentioned in the previous section, content is received either to deliver an application or to relay other nodes. The relay-selector callback of the routing

protocols receives destination addresses and an active neighbor list and decides which neighbor or neighbor set is best to carry the message. In fact, routing protocols use context information for better decision-making. SPONET has three built-in routing protocols – Epidemic [26], Spray & Focus [27], and Utility-based Routing [2], which are created using the above-mentioned RPA interfaces. Note that SPONET can be extended with other protocols via the APIs of RPA. Epidemic routing is a basic routing solution where messages are forwarded to every encountered node that does not have a copy of the same message. The header of Epidemic routing contains only a destination address and delivery deadline. Consequently, the relay-selector function of the Epidemic protocol returns all active neighbors as the next hop. Spray & Focus assigns a replication number to a message and distributes message copies to a number of carrying nodes using history encounter times and encounter rates. Similarly, the Utility-based Routing uses the history of mobility information and future contact predictions to select message-carrying nodes. The routing header of these protocols is complicated as it is comprised of the destination address, replication size, encounter rate, utilities, etc. The relay-selector function of these routing protocols returns a single node or a set of nodes according to the available context.

5. Implementation We implemented SPONET on the Android protocol stack and validated the operations on a number of smartphones, such as Nexus One, Nexus S, Samsung Galaxy S, and HTC Desire. The software-based access point (Soft-AP functionality is enabled on these devices, which are equipped with various sensors, such as GPS, GSM, an accelerometer, a digital compass, etc. SPONET is implemented as an Android service that continuously runs in the background. Although SPONET does not run in a privileged user mode (i.e., a rooted mode), which is required for some systems [9,11,12,28], not all phones provide the required functionalities for SPONET. For example, the Soft-AP functionality is enabled on some phones or the control interface is not implemented. Also,

32

E. Talipov et al. / Computer Communications 37 (2014) 25–39

accelerometer reading is disabled when the screen is turned off to save power. To identify these problems, SPONET probes these functions at the initialization stage and operates accordingly. That is, if the Soft-AP functionality is not supported, SPONET does not try to enable this function even if the other SP is not found when a new landmark is discovered. Another implementation issue is that if SPONET enables the Soft-AP mode, Wi-Fi communication with APs cannot be established. However, the problem can be solved with Wi-Fi Direct since it supports parallel connections with AP and other smartphones.

5.1. User interface In SPONET, a console like user interface (UI), which is shown in Fig. 5, is designed to assist intuitive configuration and a fast check out of the background status. The user can have a straightforward view of current or last visited landmarks and current working progress, as seen in Fig. 5(a). It also describes current activity of the user and the duration of the activity. A list of all landmarks is shown in Fig. 5(b), and the list view provides landmark details such ULID, latitude and longitude, visiting number, and last visit. By

selecting any landmark, the user may extend the information view, as in Fig. 5(c). The window displays the sensor values collected at the landmark, which consists of cellular information, Wi-Fi AP information, visit information, and neighbor information. As in Fig. 5(d), the map view shows landmarks on the map to check out users’ own mobility patterns. Fig. 5(e) demonstrates how social context can be monitored via a neighbor list window, with current contact duration and an online indicator. Thus, the connected neighbors are identified with a green indicator. A configuration panel in Fig. 5(f) is used to tune the degree of privacy-sharing and resource-sharing strategies. Finally, by selecting ‘‘Export DB’’ on the context menu, users can export their aggregated context information and networking history to the external storage of smartphone. The result is stored as a database file, which can be used as a trace for simulating DTNs.

5.2. Application programming interfaces SPONET offers APIs to perform peer-to-peer communication, similar to typical peer-to-peer data exchange systems. In addition, our system provides user context, which is the geographical and

(a) Status and Progress View

(b) Landmark List

(c) Landmark Extended Information

(d) Map View

(e) Neighbor List View

(f) Settings

Fig. 5. SPONET user interface; the user checks the status of SPONET by (a) viewing the list of landmarks he/she visited or (b) viewing detailed information on a landmark, (c) which includes a cellular network information, nearby Wi-Fi APs, visit time and duration, and encountered neighbors. The (d) map view shows approximate location of landmarks as a ‘‘star’’ icon; active (green indicator) and inactive (gray indicator) neighbors are shown in (d). User configures SPONET using the settings window (f). (For interpretation of the references to colour in this figure caption, the reader is referred to the web version of this article.)

E. Talipov et al. / Computer Communications 37 (2014) 25–39

social history of device encounters. Also, SPONET has a number of callback functions to extend its functionalities, such as adding new routing protocols and implementing neighbor discovery methods. We have categorized the SPONET’s API into three groups: the context transportation interface (CTI), the local context access interface (LCAI), and the configuration and control interface (CCI). Fig. 6 shows the list of mostly frequently used APIs and callbacks; in addition, more APIs are available in SPONET. CTI enables the advertisement, delivery, and download of data from other peers. Applications may use delivery functions to share data with others, and the application port must be specified to deliver data to the intended application. Applications should each use a unique port, although duplicated ports are allowed for the purpose of delivering the same data to multiple applications. Applications optionally specify deadlines for delivery that may facilitate delivery and avoid unnecessary distribution of the data. To receive data, the applications register callback for data receiving and specify a port. When MM receives data, it checks the application port and forwards the data to the applications with a matched port number. LCAI has the components of social and geographical context access methods. Social context is basically neighbor based and provides a link to relevant temporal and spatial encounter histories with neighbor devices. Geographical context organizes information corresponding to a specific landmark, which includes visit duration, number of visits, transitions, etc. These contexts can be used in both applications and external routing protocols. Applications use contexts for designing networking applications and user-centric applications. For example, using the landmark information and transition between landmarks a ‘‘Digital Diary’’ or ‘‘Appointment Scheduler’’ application can be implemented. In CCI, we provide access for control and configuration mechanisms on resource sharing, data exchange, and location privacy availability degrees. APIs in this group are designed for the implementation of routing protocols, controlling the behavior of SPONET on neighbor discovery, and data exchange. CCI assists with setting

33

parameters for the routing protocols. In order to reduce SPONET’s complexity, we have placed the global routing protocol strategy options in CCI, so that they will apply to all attached applications. In our future work, we plan to add more detailed settings, such as social privacy access level, the designation of routing options for each application or even each message, etc. Applications that run on SPONET need to import SPONET-specific classes such as Neighbor, Landmark, Visit, and RPA-Header, and to use Android Interface Definition Language.

5.3. Case study: a media-sharing application To validate the spontaneous networking function of SPONET, we have implemented a sample application called MusiShan (read as ‘‘musician’’). MusiShan is a media-sharing application with search and download functions. The MusiShan user interface is shown in Fig. 7. Users select their desired content to share and add tags. The list of shared content is stored in a database including the title of the content, its size, and related tags. Also, additional information can be stored according to the type of content. In case of music, this information could include artist’s name, album title, genre of music, album year, etc. In order to search for content, users insert keywords, select content type, set a download deadline, and press the search button. MusiShan generates a search query and calls the API deliverToAll (). The API uses Epidemic routing and delivers the query to every encountered device. The query is then delivered to MusiShan on the other devices and generates a response including actual content. To deliver the response, MusiShan calls the deliverTo () function, indicating the query generator node as the destination. SPONET then uses one of active routing protocols (e.g., Spray & Focus) and delivers the content to the destination. Usually, content is transferred in a single transmission between devices, but for convenience, the application shows the download progress. With only two APIs of SPONET, contents can be easily shared between smartphones on demand.

Fig. 6. Application programming interfaces provide functions to obtain information, send and receive data, and configure and extend the system.

34

E. Talipov et al. / Computer Communications 37 (2014) 25–39

(a) Search

(b) Share

(c) Download

Fig. 7. MusiShan (myu’zIS En), a media-sharing application.

600

100 Execution Time

CPU Overhead

500

70 60

300

50 40

200

Overhead (%)

80

400 Time (ms)

90

30 20

100

10 0

0 Idle stateActivity Landmark Provider detection processing enabling

Client enabling

Beacon Beacon sending processing

Fig. 8. CPU overhead and task execution time.

6. Experiments As we mentioned in Section 1, a spontaneous networking system for smartphones should exhibit the following characteristics to be pragmatic: lightweight in terms of CPU and memory overhead and efficient in resource utilization and energy consumption. Specifically, task scheduling and process management should be carefully designed since the system runs continuously in the background. Using the following experimental analysis, we demonstrate the feasibility of the spontaneous networking system for smartphones.

6.1. CPU overhead and task execution time To perform context-aware networking, our system employs the SPONET service described in Section 4. The service continuously runs in the background to discover neighbors and exchange content. Fig. 8 illustrates the CPU overhead and task execution time of various tasks carried out by SPONET. The results are an average of 100 samples for 10 test cases. We have used the Android tracing method to identify the CPU overhead and execution time per task. The overhead is caused by obtaining accelerometer readings and scheduling tasks of the MM. The accelerometer readings are then processed by the activity manager, and the activity type of the user

is detected. This process incurs an average overhead of 5:7  0:8% (standard deviation) and runs for the duration of 2.4 ms for each detection. A task with a high CPU overhead is landmark processing (i.e., landmark learning), which is performed by the context manager. The processing produces about 50% of the CPU overhead. Landmark learning is a sequence of jobs: location estimation, one-time scanning of neighboring Wi-Fi APs, comparing a landmark with the existing landmarks (i.e., matching places), and so on. Although landmark learning produces a high CPU overhead, its runtime is very short. Landmark learning runs for about 574 ms, and the running time mostly concerns retrieving existing landmarks from the database and place matching. The place similarity is tested for about 50 locations. Four tasks that are related to spontaneous networking — provider enabling, client enabling, beacon sending, beacon receiving — have a very short run time although they generate a high CPU overhead. Interestingly, enabling the provider mode generates about a 76% overhead, which is high, and runs for a very short duration (i.e., 20 ms). This is because a number of operations to control the hardware are carried out in this mode. Conversely, enabling the client mode generates about a 28% CPU overhead for 12 ms. In the client mode, a device attempts to connect to the provider’s device. Tasks such as actual connection establishment and obtaining an IP address from a provider’s DHCP server are not in-

35

E. Talipov et al. / Computer Communications 37 (2014) 25–39

cluded here. The beacon-sending and beacon-receiving tasks are part of the UDP packet processing operation. Since the size of the beacon is small, both sending and receiving the beacon takes a short time (32 to 35 ms) and generates a CPU overhead of 40.6% and 46.2%, respectively. Other tasks of SPONET, such as TCP communication, Wi-Fi scanning, and GPS reading, significantly depend on the user’s parameter settings. For instance, the overhead caused by TCP communication depends on the packet size, and the Wi-Fi scanning depends on the number and duration of scans. Analysis of the memory usage for each task is not trivial in Androids. We have estimated the maximum and minimum memory usage of SPONET to be approximately 7.4 MB and 2.4 MB, respectively.

6.2. Energy consumption Users of mobile devices are increasingly sensitive to battery time; thus, the platform should be energy efficient. We have conducted experiments to understand the power consumption of tasks and smartphone components used by SPONET. We used the Monsoon power measurement tool to measure the power consumption of SPONET running in the Nexus-One smartphone. Monsoon and the battery connector of the Nexus-One were serially connected to measure power consumption, and the measurement frequency was set to 2 kHz. Instead of using the battery, we used a DC power supply to deliver constant voltage (3.7 V) to maintain the measurement consistency. Fig. 9 illustrates the power consumption scenario that generates context and enables spontaneous networking. We divided the trace into eight regions, where the solid red line indicates the average of each region, and the green dash-dotted line indicates power consumption of the Android system. Region A shows the power consumption of the accelerometer reading and activity detection. Although the accelerometer consumes less than 4 mW, the power consumption of activity detection is about 100.5 mW, because we use the Android wake-lock function and keep the CPU continuously running. During a GPS reading time of 30 s, the average power consumption of SPONET increases to 406.3 mW, as shown in region B. Then, the GPS is turned off and Wi-Fi is turned on. SPONET scans the Wi-Fi APs three times and proceeds to landmark learning in Region E. After the landmark processing is finished, the Wi-Fi is first turned off and turned on again with a different Wi-Fi state to enable the SP mode. The process consumes approximately 593 mW on average

A

B

during a short period. Last, SPONET sends and receives beacons, which consumes between 390 to 420 mW. Fig. 10 shows the average energy consumption in a day using the measurements obtained from seven users over a period of 4 weeks [20]. Since the accelerometer was used continuously, its active time is 24 h; thus, it consumes 8.7 kJ. The average active time and standard deviation of the GPS is 4:6  1:9 min; thus, it consumes 113:1  47:2 J. Wi-Fi is required to be in idle mode during 75% of a user’s stay time, and a Wi-Fi scan is performed for every visited landmark, consuming 22.3  9.3 J in a day. Wi-Fi communication for neighbor discovering consumes 1.5  0.3 kJ in a day. The total energy consumption of the system in one day was 5.7  0.3 kJ, which is equal to 66  3.47 mW per hour. Experimental results are shown for the average case, but this may vary according to the communication pattern of the smartphone. Yet, we can state that the battery lifetime of the SPONET-installed smartphone is still sufficient for daily use. 6.3. Context-generation efficiency The context-generation accuracy of SPONET is evaluated in terms of two aspects: correct learning of context information and latency in context learning (i.e., landmark discovery latency). The landmark is the key element of context information. Hence, we first evaluate the learning accuracy with three parameters: correct learning ratio, missed landmark rate, and missed sojourn time. This experiment is carried out for 73 landmarks collected over a period of 4 weeks. For this experiment, we manually recorded the visited landmarks and the stationary duration for each landmark. As can be seen in Fig. 11, the learning accuracy was measured according to various context-learning granularities. The granularity is the minimum stationary duration required to accept a location as a landmark. Here, ‘‘correct learning’’ means that the algorithm correctly matches the candidate landmark with one of the existing landmarks. Note that the correct learning rate is calculated using only learned landmarks; i.e., unlearned landmarks are not included. The accuracy of correct learning depends on ambient Wi-Fi fingerprinting and the place-matching algorithm; it is not influenced by context-learning granularity. We identified perceived/missed landmarks and missed sojourn times by using the estimated sojourn duration. We defined missed (unlearned) landmarks as locations where spontaneous communication was possible even though the sojourn time of the user at these locations was smaller than the context-learning granularity.

C E

F G

H

D

Fig. 9. Power consumption in Nexus One; each region marked with letters indicates a task or process, namely, A: activity detection, B: turn on GPS and location sensing, C: turn off GPS, D: turn on Wi-Fi, E: Wi-Fi scanning and landmark learning, F: switch to provider mode, and G & H: sending and receiving beacons.

36

E. Talipov et al. / Computer Communications 37 (2014) 25–39 GPS

WiFi Communication

WiFi Scan

Accelerometer

3000

Landmark Discovery Late

Energy Consumption (J)

4000

2000 1000 200 100

14 12 10 8 6 4

User2

User3

User4

User5

User6

2

0 20

15 10 Context Lear ning Granula rit

0 User1

1

2

User7

Fig. 10. Average energy consumption in a day; energy consumption was computed according to users’ stationary and moving duration, which was collected over a period of 4 weeks. Here, only efficient sensor scheduling is used, and accelerometer duty cycling is not applied.

Co P e n te x rio t L d ea (w rn ee in ks g )

ncy (min)

5000

5

3

y

Fig. 12. Context learning latency.

80 100%

70%

800

60% 50%

600

40% Perceived Landmarks 30%

400

Time (seconds)

1000

80%

Missed Landmarks

20%

Correct Learning

10%

Missed Sojourn Time

200

0%

0 10

15

20

25

30

Context Learning Granularity (minutes)

Neighbor Discovery Latency

90%

Accuracy (ratio)

Wi-Fi Scan Joining Network

1200

70

Enabling Client Beacon Exchange

60 50 40 30 20 10 0 10

20

30

40

50

Beaconing Inteval (seconds)

Fig. 11. Context learning accuracy.

Fig. 13. Neighbor discovery latency.

In other words, the unlearned landmarks are the ones where user has visited but are not recorded in the database by SPONET. These locations should be learned as landmarks because there was an opportunity to communicate with other users. When the context-learning granularity is small, the ratio of unlearned landmarks to all landmarks is also small, and the ratio increases in proportion to the context-learning granularity. Consequently, the missed sojourn time also increases with increasing context-learning granularity. The missed sojourn time is the difference between the sojourn time recorded in the database by SPONET and the sojourn time that the user has manually recorded. The result also shows that in daily life, we stay for more than 30 min at 60% of the landmarks that we usually visit. Although SPONET consumes less energy with a long context-learning granularity, we miss more communication opportunities. SPONET, therefore, sets the context-learning granularity to 10 min by default, but users may control this setting to save more energy. In Fig. 12, we illustrate the relationship between latency in context learning and the context-learning granularity, as well as the context-learning period. In this analysis, we use landmark learning via landmark prediction. Thus, landmarks are not just discovered based on exact context-learning granularity, but rather are based on predicted arrival at landmarks. We use the landmark-prediction method described in Section 4.3 to estimate the approximate arrival at the next landmark. Landmark learning is initiated when a user becomes stationary for even less time than the context-learning granularity time and/or for a greater time than the estimated arrival time minus the current time. In a worst case scenario, the

landmark is learned with the latency equal to the context-learning granularity. This can significantly reduce learning latency for the landmarks with higher predictability. As shown in Fig. 12, with a 4-week learning period, the latency can be decreased to 6 min when the context-learning granularity is 10 min, and the latency can be decreased to 14 min when the context-learning granularity is 30 min. Discovering landmarks increases the opportunity of spontaneous communication since spontaneous networking is started immediately after landmark discovery. 6.4. Networking efficiency The networking efficiency of SPONET depends on how efficiently SPONET discovers neighbors and how efficiently data are transferred between mobile devices. In this section, we evaluate these two aspects of SPONET. First, neighbor discovery is an important task for routing protocols. Especially for delay-tolerant applications, efficient neighbor discovery is a key parameter to the delivery of content on time. As discussed in Section 5.2, SPONET uses the blind date method to find neighboring devices. Thus, after joining a spontaneous network group, each node generates a UDP beacon message to indicate its existence. We evaluate the efficiency of neighbor discovery via the discovery latency. The neighbor-discovery latency consists of the latency on initiating/joining a network plus latency on receiving/processing neighbor beacons. Since nodes send neighbor beacons periodically, the arrival time at the landmark also largely influences discovery latency. In Fig. 13, the neighbor-discovery latency is estimated according to

E. Talipov et al. / Computer Communications 37 (2014) 25–39

varying beacon intervals using 100 samples. With increasing beacon intervals, the neighbor-discovery interval increases due to the late reception of neighbor beacons. In a worst case scenario, the beacon-exchange latency is equal to the beaconing interval. Note that a beacon exchange includes the waiting interval until the next beacon after arriving at the landmark in addition to a delay in beacon processing. Here, the device is assumed to be a spontaneous client and joins a spontaneous network. Therefore, scanning neighboring APs, enabling the client mode, and joining a network are inevitable steps. The delay in these steps has very small variation and is not influenced by the beaconing interval. Next, we show the networking efficiency of SPONET in terms of round trip time (RTT), as shown in Fig. 14 packet loss, and throughput, as shown in Table 1. We have developed a ping application and estimated the RTT between devices using diverse communication types. We used Nexus-One as the mobile device and the IEEE802.11n base station as an AP. In this analysis, we have found that RTT varies in relation to distance between devices because signal attenuation is different. Our experiments were carried out in realistic scenarios; thus, the devices were non-line-of-sight, and about 10 other APs existed nearby that were interfering with communication. Distance between devices is 10 meters for the estimated packet-loss ratio, which is the ratio of lost packets to packets sent, and throughput. Results indicate that SPONET has a significant advantage over the Wi-Fi ad hoc mode and Bluetooth communication both in terms of throughput and packet-loss rate. Packet loss ratio is low in Wi-Fi ad hoc mode and Bluetooth communication due to the device characteristics. If two devices use Wi-Fi ad hoc mode or Bluetooth interface to communicate with each other, interference to the communication from other wireless devices becomes high due to the device/protocol characteristics, especially when the distance between devices is long. Consequently, the communication efficiency drops significantly. In SPONET, the Wi-Fi infrastructure mode, i.e. the Soft-AP mode, as well as the link state management method help improving the communication efficiency. 7. Related work Previous work has often addressed SSNs as PSN, delay- and disruption-tolerant networks, or opportunistic networks. In this section, we discuss the known implementations of such network architectures. Among the implementations, DTN implementations are prominent. DTN2, which was developed by the Delay-Tolerant Networking Research Group [9], was implemented to demonstrate basic functionalities and therefore was found not to operate efficiently. The interplanetary overlay network (ION) [29] is an implementation of the DTN bundle protocol, Licklider transmission protocol (LTP), and the CCSDS file-delivery protocol and asynchronous message service. The intent of the ION distribution is to support high-speed, small-footprint deployment of DTNs in embedded systems such as robotic spacecraft, but it also runs well in more resource-rich environments, such as local-area networks [29]. IBRDTN [7] is a lightweight implementation that was designed to run on embedded devices as well as on standard Linux systems. IBR-DTN’s architecture consists of an overlay, called the bundle layer, which operates above the transport layer. The goal is to Table 1 Packet loss rate and throughput.

Mobile Mobile Mobile Mobile

to to to to

PC (via Mobile Mobile Mobile

W LAN) (Ad hoc) (SPONET) (Bluetooth)

Packet loss ratio (%)

Throughput (Kbps)

2.5 13.4 3.4 53.2

2779 823 2695 237

37

Fig. 14. Packet round trip time.

deliver data units called bundles from a sender to a receiver in the presence of opportunistic connectivity. Thanks to the bundle layer, DTN implementations support a variety of delay-tolerant applications. However, they are not targeted at smartphones and hence do not consider the constraints that are mentioned in Section 1. In the case of opportunistic network implementations, Haggle [12] is an architecture for mobile devices that facilitates the separation of application functionality from the underlying network technology to provide seamless operation despite disruptions in network connectivity. It is composed of a number of modular building blocks. Connectivity is achieved based on the late binding of network interfaces, protocols, and names. Haggle is not a strict architecture, but rather proposes a node design that allows applications to adapt to the network connectivity level. DASM [30] is an implementation of the DTN family of protocols for Symbianbased mobile phones. DASM includes implementations of bundle protocol v4 [31], a TCP convergence layer, and a Bluetooth convergence layer. Trifunovic et al. [36] presented an opportunistic network using Wi-Fi without ad hoc mode support. The proposed method used a similar peer-to-peer networking method to the spontaneous network method used in our work, which does not require a privileged user mode in the Android framework. However, context awareness is out of the scope of this paper, which does not consider a user context-aware opportunistic network. To extend legacy applications, such as web and e-mail to opportunistic environments, Moghadam [11] implemented a modular platform that provides application developers with core functionalities required for mobile disruption-tolerant communication. Since the platform was designed for general purpose applications, the platform lacks optimizations and context-aware networking opportunities. Cimbiosys [32] is a platform that provides content synchronization and replication through opportunistic peer-topeer communication. It uses content-based filters to specify what content is synchronized and shared by the system. BlueTorrent [8] is an opportunistic file-sharing application only for Bluetoothenabled devices. Karlsson et al.[14] presented an idea of a delaytolerant broadcast system, evaluated its feasibility in an urban area, and implemented it in [28]. May et al. introduced podcasting as an application for DTN in [15] and implemented it and further analyzed it in [37]. With a widespread use of mobile games and social networking on smartphones, various peer-to-peer smartphone network frameworks [11,33,34] are especially developed for social networking and gaming purposes. Thomas et al. [11] demonstrated a mesh networking on the Android framework. The scheme uses the Wi-Fi Direct communication technology to establish one-hop

38

E. Talipov et al. / Computer Communications 37 (2014) 25–39

communication and adopts existing MANET routing protocols for multi-hop communication. Konstantinidis et al. [33] demonstrated a framework for finding objects (e.g., images, videos, etc.) captured by the users in a mobile social community. The framework uses an in situ storage model, in which the captured objects are stored locally on smartphones, and searching takes place over a dynamically computed lookup structure. Le et al. [34] discussed MicroPlay, which is a networking framework for multiplayer mobile games within the LAN. The framework provides low latency in gaming and simplifies game development. In summary, we can state that previous implementations are either designed for special purpose applications or they implemented a generic DTN architecture. Implementations for special purpose applications are neither extensible nor context aware. On the other hand, although implementations based on generic DTN architecture are extensible, they are not practically usable on smartphones, as some of them require active user intervention (e.g., pairing-up devices), while others require modifications to the software architecture. Our implementation is purely based on the current software architecture of smartphones and available sensors. Also, our implementation is instantly usable on commercial smartphones and provides efficient context-aware networking with low CPU overhead. 8. Conclusion In this paper, we designed, implemented, and evaluated SPONET, which provides a context-aware spontaneous networking environment for delay-tolerant applications and services. The core component of SPONET is context generation and spontaneous networking. Our place-learning algorithm generates physical/logical location information, and a dynamic neighbor-discovery algorithm provides efficient interaction between smartphone users in everyday life. SPONET’s networking policy allows applications to exchange data without the intervention of users. Previous work has not provided efficient context-aware networking. They either require modifications to the software architecture of smartphones to implement the communication method or they required active-user intervention in establishing communication. Our goal was to avoid such steps for users and to implement a practical system on commercial smartphones. We have implemented SPONET on commercial Android smartphones and validated its correct operation. Although SPONET only uses about 6% of CPU overhead, its energy consumption is still high. The main source of energy consumption is keeping the CPU awake for activity detection with the accelerometer. We believe that the system will benefit from technologies such as AMP [35] and multi-interface wireless communication that will soon be available on smartphones. Moreover, accurate synchronization of beacon transmission and reception would reduce energy consumption that is caused by longer waiting duration for receiving beacons. Finally, SPONET needs to be evaluated with various application-related metrics such as scalability, density, limited bandwidth, and so on. We plan to address these issues in our future work. Acknowledgement This work was supported by a National Research Foundation of Korea Grant funded by the Korean government, Ministry of Education, Science and Technology (Nos. 2013-027363, 2013-023635). References [1] V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss, Delay-tolerant network, architecture, RFC4838, January 2007.

[2] J. Wu, M. Lu, F. Li, Utility-based opportunistic routing in multi-hop wireless networks, Proceedings of the 28th Int’l Conference on Distributed Computing Systems, IEEE Computer Society, Washington, DC, 2008, pp. 470–477. [3] Q. Yuan, I. Cardei, J. Wu, Predict and relay: an efficient routing in disruptiontolerant networks, in: Proceedings of the 10th ACM Int’l Symposium on Mobile Ad Hoc Networking and Computing, New York, NY, 2009, pp. 95–104. [4] A. Lindgren, P. Hui, The quest for a killer app for opportunistic and delaytolerant networks (invited paper), in: CHANTS ’09: Proceedings of the 4th ACM Workshop on Challenged Networks, New York, NY, pp. 59–66. [5] A. Martínez, V. Villarroel, J. Seoane, F. Del Pozo, Analysis of information and communication needs in rural primary health care in developing countries, IEEE Transactions on Information Technology in Biomedicine 9 (1) (2005) 66– 72. [6] R. Dingledine, N. Mathewson, P. Syverson, Tor: the second-generation onion router, in: Proceedings of the 13th USENIX Security Symposium, Boston, MA, August 2004, pp. 303–320. [7] S. Schildt, J. Morgenroth, W.B. Pöttner, L. Wolf, IBR-DTN: a lightweight, modular and highly portable bundle protocol implementation, in: Electronic Communications of the EASST, vol. 37, January 2011, pp. 1–11. [8] S. Jung, U. Lee, A. Chang, D. Cho, M. Gerla, BlueTorrent: cooperative content sharing for Bluetooth users, in: Proceedings of Pervasive Mobile Computing, White Plains, USA, 2007, pp. 609–634. [9] P. Meroni, E. Pagani, G.P. Rossi, L. Valerio, An opportunistic platform for Android-based mobile devices, in: The Proceedings of the 2nd International Workshop on Mobile Opportunistic Networking, New York, NY, 2010, pp. 191– 193. [10] A. Elwhishi, P. Ho, K. Naik, B. Shihada, A novel message scheduling framework for delay tolerant network routing, IEEE Transactions on Parallel and Distributed Systems 24 (5) (2012) 871–880. [11] J. Thomas, J. Robble, Off-grid communications with Android, MITRE Corporation Technical Paper, July 2012. Online: . [12] J. Su, J. Scott, P. Hui, J. Crowcroft, E. Lara, C. Diot, A. Goel, M. Lim, E. Upton, Haggle: seamless networking for mobile applications, Proceedings of 9th International Conference on Ubiquitous Computing, Springer, Innsburg, Austria, 2007, pp. 391–408. [13] A. Moghadam, S. Srinivasan, H. Schulzrinne, 7DS – A modular platform to develop mobile disruption-tolerant applications, Proceedings of the 2nd IEEE International Conference on Next Generation Mobile Applications, Services, and Technologies, IEEE Computer Society, Cardiff, Wales, UK, 2008, pp. 177– 183. [14] G. Karlsson, V. Lenders, M. May, Delay-tolerant broadcasting, in: Proceedings of ACM SIGCOMM, Challenged Networks Workshop, Pisa, Italy, 2006, pp. 369– 381. [15] V. Lenders, M. May, G. Karlsson, Wireless ad hoc podcasting, in: Proceedings of Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks, San Diego, CA, 2007, pp. 65–67. [16] Wi-Fi Alliance, Wi-Fi Peer-to-Peer (P2P) Technical Specification, ver. 1.1, 2010. [17] Y. Chon, H. Cha, LifeMap: Smartphone-based context provider for locationbased service, IEEE Pervasive Computing Magazine. http://dx.doi.org/10.1109/ MPRV.2011.13. [18] Y. Chon, E. Talipov, H. Cha, Autonomous management of everyday places for personalized location provider, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Application and Reviews 42 (4) (2012) 518–531. IEEE SMC Society. [19] P. Jaccard, The distribution of the flora in the alpine zone, New Phytologist 11 (2) (1912) 37–50. [20] D. Eastlake, et al. US Secure Hash Algorithm 1 (SHA1). RFC 3174, September 2001. [21] Y. Chon, E. Talipov, H. Shin, H. Cha, Mobility prediction based smartphone energy optimization for everyday location monitoring, in: Proceedings of the 9th ACM Conf. on Emb. Net. Sensor Sys. Seattle, WA, 2011, pp. 82–95. [22] J. Biesterfeld, E. Ennigrou, K. Jobmann, Neural networks for location prediction in mobile networks, Proceedings of International Workshop on Applications of Neural Networks to Telecommunications, Lawrence Erlbaum Associates, Mahwah, NJ, 1997, pp. 207–214. [23] L. Song, D. Kotz, R. Jain, X. He, Evaluating next-cell predictors with extensive Wi-Fi mobility data, IEEE Transactions on Mobile Computing 5 (12) (2006) 1633–1649. [24] J.D. Camp, E.W. Knightly, The IEEE 802.11s Extended Service Set Mesh Networking Standard, IEEE Communications Magazine 46 (8) (2008) 120–126. [25] R. Rivest, The MD5 message-digest algorithm, RFC1321, April 1992. [26] A. Vahdat, D. Becker, Epidemic routing for partially connected ad hoc networks, Duke University, Durham, NC, Tech. Report CS-200006, April 2000. [27] T. Spyropoulos, K. Psounis, C.S. Raghavendra, Efficient routing in intermittently connected mobile networks: the multiple-copy case, IEEE/ACM Transactions on Networking 16 (1) (2008) 77–90. [28] O.R. Helgason, A.E. Yavuz, T.S. Kouyoumdjieva, L. Pajevic, G. Karlsson, A mobile peer-to-peer system for opportunistic content-centric networking, in: Proceedings of the 2nd ACM SIGCOMM workshop on Networking, Systems, and Applications on Mobile Handhelds, New York, NY, August 2010, pp. 21–26. [29] Interplanetary overlay network project, . [30] T. Hyyryläinen, T. Kärkkäinen, C. Luo, V. Jaspertas, J. Karvo, J. Ott, Opportunistic email distribution and access in challenged heterogeneous environments, in: Proceedings of ACM SIGCOMM CHANTS, Montreal, Canada, 2007, pp. 97–100. [31] K. Scott, S. Burleigh, Bundle protocol specification, RFC5050, November 2007.

E. Talipov et al. / Computer Communications 37 (2014) 25–39 [32] V. Ramasubramanian, T.L. Rodeheffer, D.B. Terry, M. Walraed-Sullivan, T. Wobber, C.C. Marshall, A. Vahdat, Cimbiosys: a platform for content-based partial replication, in: Proceedings of USENIX Symposium on Networked Systems Design and Implementation, Massachusetts, Boston, 2009, pp. 261– 276. [33] A. Konstantinidis, C. Aplitsiotis, D. Zeinalipour-Yazti, SmartP2P: a multiobjective framework for finding social content in P2P smartphone networks, Demo at the 13th IEEE International Conference on Mobile Data Management (MDM’12), IEEE Computer Society, Bangalore, India, 2012, pp. 23–26. [34] A. Le, L. Keller, C. Fragouli, A. Markopoulo, MicroPlay: a networking framework for local multiplayer games, in: Proceedings of the 1st ACM International Workshop on Mobile gaming, Helsinki, Finland, August 15, 2012, pp. 13–18.

39

[35] B. Priyantha, D. Lymberopoulos, J. Liu, Enabling energy-efficient continuous sensing on mobile phones with little rock, in: Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks, Stockholm, Sweden, 2010, pp. 420–421. [36] S. Trifunovic, B. Distl, D. Schatzmann, F. Legendre, WiFi-Opp: ad hoc-less opportunistic networking, in: Proceedings of the 6th ACM Workshop on Challenged Networks (CHANTS’11), Las Vegas, USA, 2011, pp. 37–42. [37] M. May, V. Lenders, G. Karlsson, C. Wacha, Wireless opportunistic podcasting: Implementation and design tradeoffs, in: Proceedings of the 2nd ACM Workshop on Challenged Networks (CHANTS ’07), Montreal, Canada, 2007, pp. 75–82.