An Investigation Into Trafc Analysis for Diverse Data Applications on Smartphones

Sudhir Kumar Baghel, Kirti Keshav & Venkateswara Rao Manepalli

Samsung India Software Oprations Pvt. Ltd. Email:{sudhirb, kirtik, venkat.mane}@samsung.com

AbstractPresent day smartphones like iPhone and Andriod based phones have lead to explosive growth in trafc over cellular networks. The growth has occurred both in volume and diversity in terms of trafc characteristics. Among the different types of trafc, there is prominent increase in background type of data due to popularity of applications like Facebook, Skype, Email clients etc which keeps exchanging data with corresponding server, even when the user is not actively using the application. In order to save power consumption of smart phones and for optimal allocation of resources to deserving phones in network by minimum possible signaling trafc, 3GPP LTE specications have dened mechanisms like connected mode DRX (Discontinuous Reception) which offers two stage of sleep in form of long & short DRX. Since such diverse type of applications are running in smartphone, this work attempts to investigate trafc characteristics of popular applications in Andriod based smartphones. Due to various reasons, such applications, keep consuming precious bandwidth and battery even when not in active use. Main emphasis is thus provided to study the characteristic of these applications when they are running without user intervention. Since, the diverse range of data characteristics is assumed to be causing drain in User Equipment (UE) battery and overhead in NW signaling, we expect that this investigation would help in developing appropriate new power saving mechanisms in future releases of cellular networks.

However one good thing is that in LTE connected DRX parameters are already user specic though they are still not application specic. 2) Even though there is a huge diversity in types of applications running in UE, still more than 60% of the trafc is because of HTTP and HTTPS [5][6]. Theoretical HTTP model was designed primarily from web browsing behavior point of view whereas presently largest portion of this trafc is usually attributed to multimedia and specically video. This trend is only going to be more dominant in future. 3) Another important set of applications which adds to immense diversity of trafc are social media applications like Facebook & Skype. Generally user will assume that having signed in, if one is not using skype actively, such applications wouldnt consume data and would allow UE to sleep. However since skype works on P2P principles, even if user is not using the application, skype framework is using smartphones computational and bandwidth resources for other users data. Based on above discussion it is clear that there is diversity in data trafc characteristics of different applications running in a UE. For an effective investigation on the sufciency of the current LTE DRX mechanisms to handle increase in trafc in energy efcient & optimal way, background trafc analysis is of high importance [7]. Background trafc mainly consists of trafc from unattended phone with applications not in active phase. Since Andriod is one of the most popular smartphone OS, we used android smartphone as a base for our study. We however believe that, our study is valid for other prospective smartphones such as those based on Windows & iPhone. The rest of the paper is organized as follows. In section II, a detailed description of experiments performed for diverse data applications and results obtained for important applications are presented. Later analysis on trafc characteristics for applications such as facebook, skype and persistent TCP based applications in section 2. Then a brief analysis on efcacy of power saving mechanisms present in 3GPP 3G & 4G specications is given in section III. Finally appropriate conclusions based on results of our investigation are presented in section IV.

I. I NTRODUCTION With the advent of powerful processors and huge bandwidth availability, background applications such as Facebook, Skype, Email Exchange, Messengers are widely becoming popular. This has given rise to huge amount of trafc over cellular networks. It is assumed that with diverse range of data applications running, UE can generate trafc which can be of diverse in nature. This diverse nature of data trafc leads to drain in UE battery and signaling overhead in the network if existing DRX mechanism in LTE[1][2]are not exible enough to accommodate the diversity. In order to discover new mechanisms, it is however important to rst understand the nature of problem and all the dimensions of it. There are certain details which can help us understand the problem scope in detail to some extent. 1) It has been studied [4] and found out that smartphone usage varies very signicantly from one user to another user. This implies that, on top of diversity in the characteristics of applications there is one more level of diversity due to usage pattern. So we should infer that optimizations done for average case may actually make the solution ineffective for larger section of users.

978-1-4673-0816-8/12/$31.00 2012 IEEE

Fig. 1.

Trafc Pattern of all the captured packets Fig. 2. Trafc pattern after ltering out NBNS and ICMP packets

II. E XPERIMENTS FOR TRAFFIC CHARACTERISTICS D IVERSE DATA APPLICATIONS

OF

In this work, we shall present and discuss various types of application in following order. First the effect of Facebook application will be discussed followed by discussion on idle mode behavior of Skype application when user is not actively using the application. Thereafter, efcacy of keep alive mechanism for applications using persistent TCP connection will be studied. A. Facebook For this application, two cases are considered i.e., using android facebook application & browser based facebook access. 1) Facebook through an android application: To perform this experiment [8] all the applications except Facebook application in the phone were closed. After few minutes of the start of the application, trafc was captured using wireshark. Phone was kept Idle and no human interaction was performed. Trafc trace was collected for 90 Minutes. Trafc pattern of the captured packets is shown in Figure 1. It is observed that there are idle times of several minutes in between packets at multiple instances. We analyzed each packet and found that there are several packets of type NBNS and ICMP between the phone and some device within the network. These packets can be related to networkservices discovery in the local network. Using Wireshark lter we ltered out all such packets because they do not belong to application data. Figure 2 shows the trafc pattern after ltering out NBNS and ICMP packets. Traces for gure 2 were further analyzed and it was found that most packets are exchanged from only two ports. First one is HTTPS (TCP port number 443) and second one is TCP Port Number 5228. Also we checked all the IP address as displayed in traces and found that packets for Facebook IP addresses are only using HTTPS. To nd out the domain to which a particular IP address belongs to, was done using [14]. TCP port number 5228 is associated with IP addresses which belongs to Google Inc. Some search in Internet revealed that this is mainly used for Android Market. So it is possible that those packets belong to software upgrade of installed applications. To get closer to packets from Facebook we further applied a lter on wireshark logs to display packets for HTTPS port

Fig. 3.

Trafc pattern for HTTPS trafc only

only. Figure 3 shows the trafc pattern after applying such a lter. From Figure 3 it can be seen that majority of the packets are for Facebook (IP addresses which belong to Facebook Inc). However still some packets as marked in red in the Figure 3 are exchanged with Google server. Packet information in wireshark reveals that these packets contain data related to authentication with Google server. However the periodicity of such trafc with Google is not high and it seems that phone authenticate itself with Google at some periodicity using Gmail ID. After this step we ltered out all those packets which are exchanged with Google server to get exact trafc pattern for Facebook. Figure 4 shows the trafc pattern only for the Facebook for 90 minutes without user interaction. From Figure 4 it seems that there are Idle gaps of several minutes between activity of Facebook application in the Android based smartphone. Also it seems that Facebook intelligently increases the gap between activities, if user is not using the phone, to save battery. It is also observed that the activity with Facebook starts after opening connection with Facebook Server and after data exchange for few seconds, connection is closed. Since the TCP connection is not persistence we didnt observe Keep alive message. Our results are very much different than results obtained on Windows 7 computer as presented in [3]. On Windows 7, maximum idle gap between two packets is less than 40

Fig. 6.

Trafc Pattern for Skype App in Andriod

Fig. 4.

Trafc pattern for Facebook App in Android

Fig. 5.

CDF of the packet size (Bits) for Facebook App data

seconds whereas in android smartphone it is in the order of 30-60 minutes. Figure 5 shows the Cumulative Distribution function (CDF) of the packet size in bits for Facebook data (as selected to draw the Facebook trafc pattern in Figure 4). This CDF is more or less similar to what it has been presented in [3] for Facebook data on Windows 7 Computer. 2) Facebook access using web browser: We performed the same exercise of collecting trafc from facebook in Idle when web browser is used to login into Facebook account. After logging into Facebook we started the trace collection after some time to capture steady state logs and kept the phone Idle for 90 mins. We didnt nd any activity for Facebook in the log. This could be because as soon as phone screen gets automatically locked, all the connections are closed. B. Skype In [3], authors have analyzed background trafc generated by an idle laptop connected to a live HSPA network for Skype activity. However we wished to investigate if Skype application characteristics when performed by smartphone differs from

when performed on Laptop. To perform this experiment [9] we closed all the applications in the phone and started only the Skype application. During experiment, phone was kept idle and no human interaction was performed. Trafc pattern of all the captured packets is shown in Figure 6. Skype uses heavy cryptographic techniques, so deep packet analysis was not possible. Some more important observations were :1) Skype traces contains very diverse range of TCP ports and balanced mix of TCP and UDP ports are used, so it was not possible to distinguish Skype packets just by ltering one particular type of port. 2) There were huge number of IP addresses (close to 350) in trace collected for 5 hours duration. This could be because Skype uses peer-to-peer architecture and so data didnt solely belong to user. 3) All the packets in Skype are encrypted so it is difcult to nd packet details. 4) Due to these limitations, it was also not possible to conrm with certainty that certain captured packet belongs to Skype or not? Because of above mentioned reasons, analysis is different from Facebook application in [8]. Figure 7 shows the CDF of the packet Size in bits for Skype This CDF is more or less similar to what it has been presented in [3] for Facebook data on Windows 7 Computer. In case of [3] 90% of data is less than 500bits for Windows 7. However in case of Android 90% data is less than 1000 bits. C. Persistent TCP based Applications In this section, we are going to discuss persistent TCP based application [10]. Examples of such applications include Push Mail & other chat applications such as IMS chat. In such applications, periodic exchange of messages between client and server occurs so that TCP connection is kept alive. There is no guideline as to what that period should be and hence timer values solely depend upon the application synchronization needs. When multiple such applications are running in Smartphone, it is really very difcult to predict the overall periodicity of message exchange between network and smartphone. Hence, future DRX mechanisms should take care of such applications. If there are no messages to be exchanged, keep alive messages are exchanged to maintain the TCP connection.

3)

4)

5)

Fig. 7.

CDF of the Packet Size (Bits) for Skype App data

6)

Keep-alive messages which are short and frequent, are one of the main components of background trafc. These keepalive messages are important because of the presence of middle boxes i.e. NAT (Network Address Translators) and Firewall in the cellular network. NAT is connected to limited number of publicly rout-able IP address and translates the local IP addresses used inside the cellular Network to the public address. This way, Network can provide data services to large number of users through small number of public addresses. NAT keeps track of active connections so that it is able to translate incoming packets to correct local addresses [11]. Firewalls are deployed in cellular NW to protect the users from various types of attacks. Typically only the entities inside the cellular networks are allowed to initiate a new connection. Packets coming from outside the NW are dropped unless they are part of existing connection. Timers are used to disconnect connections which are idle for long. The conguration of expiry timer is a trade-off between frequency of keep-alive messages, large amount of memory required to maintain the state of already ended connections and exposure of user port, available number of public IP address etc. The expiry timer values vary to a large extent from operator to operator [12]. Application developers are usually not aware of the congurations and choose very conservative values for keep-alive messages. This knowledge mismatch leads to much higher frequency of keep-alive messages than actually required. However there are several interesting directions which are emerging from various domains such as: 1) SDKs of platforms provide means to have long lived connection and developer can use single long lived connections to send messages from several applications. With this developers need not deal with different timer values in different network[10]. 2) It is found that some operators are setting relatively high

7)

timeout values for certain ports as an optimization e.g. for Googles push service framework [12]. Batch scheduling of recurrent applications as provided by platforms [10]. For example, in android, developers can use API inexact repeating. If this API is used, platform will perform time alignment of multiple such timeouts, in such a way that if those applications have to send messages then those messages can be sent in one stretch. There is a possibility that a module (as application or part of platform) can be introduced in future to perform NAT traversal and rewall policy detection by UE for the current network. Using this knowledge, UE can adapt keep-alive message frequencies and numbers of such messages can be reduced [12]. IETF BEHAVE working group recommend a timeout value for 124 minutes for TCP [12] whereas currently networks are using much smaller values which can probably be increased in due course of time by Operators. NATs will not be generally needed for IPv6. However rewall would still be a must [12]. In future, this will allow relaxed timeout value as network wouldnt have to worry about limited available public IP addresses. It is possible that UE can negotiate with network for longer timeout using some signaling protocols such as NSIS or SIMCO [12]. However they are not currently much supported.

Large number of UEs and badly written applications will still be causing issues in terms of total number of small frequent messages for NW signaling overload. While performing enhancements in LTE to handle diverse range of applications, it would be better that LTE specication itself provide some mechanism rather than depending on solutions from other domains. III. S IMULATION
AND

R ESULTS

Background trafc usually can be classied as light background trafc and heavy background trafc. Facebook shows the characteristics for light background trafc and Skype shows characteristics for heavy background trafc. As seen, light background trafc for applications such as facebook is quite sparse, so it does not create much from signaling overhead & battery consumption point of view. However, heavy background trafc such as that of Skype, can contribute to huge increase in signaling overhead and battery consumption. In order to analyze the effect of heavy background trafc on LTE networks, we fed the trace shown in Figure 6 into the in house developed LTE simulator with DRX functionality. Fig 8 and g 9 shows the outcome of results from the simulator depicting the effect of Skype on LTE with different values of connection release timer and different DRX congurations. Figure 8 shows the number of connection open request and total time UE spent in connected and idle states for different values of connection release timer. Usually the connection release timer in commercial LTE network are observed as to

Number of Idle to Connected Attempts or Time in Minutes

be 10 seconds, so gure 9 shows total time spent in active DRX ON & OFF for different DRX congurations. IV. P OSSIBLE
SOLUTION DIRECTIONS

800

700

Idle to Connected Attempts Idle Time(Minutes) Connected Time(Minutes)

600

As observed from Figure 8 & 9, longer values of connection release time and longer DRX period can provide battery saving and fewer signaling overheads, however further enhancements are also possible as described in following ways. 1) Different applications have different characteristics. Since UE is in the best position to know what all applications are running, it will be optimal if UE can itself suggest to network about DRX congurations which will lead to battery savings. 2) Deep Packet Inspection (DPI) are becoming common feature in NW. NW can nd out what all applications are running in the UE based on packet analysis and it can correspondingly set the optimal DRX pattern. 3) It is possible that in UE when background trafc is getting generated there can be sudden burst of active trafc. For example user watching video for some time and then again background trafc starts. If multiple DRX congurations are made in advance and either UE or eNB just signal which DRX conguration will be in use from now can lead to battery savings. 4) In case of heavy back ground trafc (e.g. Skype) as can be seen that there can be frequent connection opening and closing if call release timer is set to low value. Though this can save battery power to some extent because now UE can be in Idle state for longer time. Connected mode DRX can possibly give the same amount of power saving as compared to Idle mode so it is possible to UE in connected state longer even if no data packet is coming for longer time. This can reduce number of connection opening and subsequently will reduce the overhead signaling. However based on UE mobility handover signaling can increase. Long lived connection coupled with setting release timer based on UE mobility is a good solution direction. In this case eNB will keep slow moving UEs into connected state longer than fast moving UEs. 5) Since background trafc packets are delay tolerant so it is possible to aggregate more than one packet at MAC/RLC level and then sending them together. With this it is possible to save battery. V. C ONCLUSION We have investigated effect of popular applications such as Facebook, Skype, Email exchange on power saving mechanisms available in present day 4G LTE networks. We nd that while Facebook, Email exchange kind of application can run in energy efcient way due to short and long drx cycle mechanisms, Skype kind of trafc is very difcult to handle. To achieve battery saving and fewer signaling overhead, it is required to enhance the LTE specications in order to accommodate the possible directions mentioned in section 4.

500

400

300

200

100

10

20

30

40

50

60

70

80

90

100

Connected to Idle Release Timer [1 5 10 30 50 70 100] ms

Fig. 8. timer

Skype performance with respect to Connected to Idle (C2I) release

80 70 60 50 40 30 20 10 0 10

DRX ON Time (Minutes) DRX OFF Time (Minutes)

Time in Minutes

15 20 25 30 35 40 45 Connected to Idle Release Timer 10 Seconds, DRX ON Duration = 5ms, DRX Cycle = [10 20 30 40 50] ms, Inactivity Timer = 5ms

50

Fig. 9.

Skype trace with DRX conguration

R EFERENCES
[1] Bontu,C et al. DRX mechanism for power saving in LTE IEEE Communications Magazine, Volume 47, Issue 6, June 2009 pp: 48-55 [2] Kuo-Chang Ting et al.Energy-Efcient DRX Scheduling for QoS Trafc in LTE Networks IEEE 9th International Symposium on Parallel and Distributed Processing with Applications (ISPA), 2011 [3] R2-114303, Analysis of background trafc characteristics, Ericsson, STEricsson [4] Hossain Fallaki et al Diversity in smartphone usage 8th International conference on mobile systems MobiSys 10, June 2010. [5] Gregor Maier et al First look at mobile handheld device trafc,11th international conference on Passive and active measurement, 2010. [6] Hossain Falaki et al A First Look at Trafc on Smartphones 10th annual conference on Internet measurement, IMC 10, 2010 [7] Chaimans notes 3GPP RAN2 #75 Athens Greece www.3gpp.org/ftp/tsg ran/WG2 RL2/TSGR2 75/Report/ [8] R2-115429 Samsung Analysis of Facebook application in Android Smartphone, 3GPP RAN2 #75Bis October 2011 [9] R2-115431 Samsung Analysis of Skype application in Android Smartphone, 3GPP RAN2 #75Bis October 2011 [10] R2-115432 Samsung Analysis of cause of frequent keep-alive messages, 3GPP RAN2 #75Bis October 2011 [11] H. Haverinen et al. Energy Consumption of always-On Applications in WCDMA Networks IEEE Vehicular Technology Conference 2007 [12] Z. Wang et al. Untold story of middleboxes in cellular networks ACM SIGCOMM 2011, August 2011 [13] Apple Push Notication Service. www.support.apple.com/kb/HT3576 [14] Trusted Source www.trustedsource.org