an investigation into traffic analysis for diverse data applications on smartphones

7/28/2019 An Investigation Into Traffic Analysis for Diverse Data Applications on Smartphones

1/5

An Investigation Into Traffic Analysis for Diverse

Data Applications on Smartphones

Sudhir Kumar Baghel, Kirti Keshav & Venkateswara Rao ManepalliSamsung India Software Oprations Pvt. Ltd.

Email:{sudhirb, kirtik, venkat.mane}@samsung.com

AbstractPresent day smartphones like iPhone and Andriodbased phones have lead to explosive growth in traffic over cellularnetworks. The growth has occurred both in volume and diversityin terms of traffic characteristics. Among the different types oftraffic, there is prominent increase in background type of datadue to popularity of applications like Facebook, Skype, Emailclients etc which keeps exchanging data with correspondingserver, even when the user is not actively using the application.

In order to save power consumption of smart phones and foroptimal allocation of resources to deserving phones in network byminimum possible signaling traffic, 3GPP LTE specifications havedefined mechanisms like connected mode DRX (DiscontinuousReception) which offers two stage of sleep in form of long &short DRX. Since such diverse type of applications are runningin smartphone, this work attempts to investigate traffic character-istics of popular applications in Andriod based smartphones. Dueto various reasons, such applications, keep consuming preciousbandwidth and battery even when not in active use. Mainemphasis is thus provided to study the characteristic of theseapplications when they are running without user intervention.Since, the diverse range of data characteristics is assumed to becausing drain in User Equipment (UE) battery and overhead inNW signaling, we expect that this investigation would help in

developing appropriate new power saving mechanisms in futurereleases of cellular networks.

I. INTRODUCTION

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 traffic over cellular

networks.

It is assumed that with diverse range of data applications

running, UE can generate traffic which can be of diverse in

nature. This diverse nature of data traffic leads to drain in UE

battery and signaling overhead in the network if existing DRX

mechanism in LTE[1][2]are not flexible enough to accommo-

date the diversity. In order to discover new mechanisms, it is

however important to first 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 significantly from one user to an-

other 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.

However one good thing is that in LTE connected DRX

parameters are already user specific though they are still

not application specific.

2) Even though there is a huge diversity in types of appli-

cations running in UE, still more than 60% of the traffic

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 traffic is usually attributed to multimedia and

specifically video. This trend is only going to be more

dominant in future.

3) Another important set of applications which adds to

immense diversity of traffic 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 traffic characteristics of different applications running in

a UE.

For an effective investigation on the sufficiency of the

current LTE DRX mechanisms to handle increase in traffic

in energy efficient & optimal way, background traffic analysis

is of high importance [7]. Background traffic mainly consists

of traffic 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. Wehowever 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 applica-

tions are presented. Later analysis on traffic characteristics

for applications such as facebook, skype and persistent TCP

based applications in section 2. Then a brief analysis on

efficacy of power saving mechanisms present in 3GPP 3G &

4G specifications is given in section III. Finally appropriate

conclusions based on results of our investigation are presented

in section IV.

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


2/5

Fig. 1. Traffic Pattern of all the captured packets

II . EXPERIMENTS FOR TRAFFIC CHARACTERISTICS OF

DIVERSE DATA APPLICATIONS

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, efficacy of keep alive mech-

anism for applications using persistent TCP connection will

be studied.

A. Facebook

For this application, two cases are considered i.e., using an-

droid facebook application & browser based facebook access.

1) Facebook through an android application: To perform

this experiment [8] all the applications except Facebook ap-

plication in the phone were closed. After few minutes of thestart of the application, traffic was captured using wireshark.

Phone was kept Idle and no human interaction was performed.

Traffic trace was collected for 90 Minutes. Traffic 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 filter we filtered out all such packets because

they do not belong to application data. Figure 2 shows the

traffic pattern after filtering out NBNS and ICMP packets.Traces for figure 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 find 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 filter on wireshark logs to display packets for HTTPS port

Fig. 2. Traffic pattern after filtering out NBNS and ICMP packets

Fig. 3. Traffic pattern for HTTPS traffic only

only. Figure 3 shows the traffic pattern after applying such a

filter. 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 traffic with Google is not high and it seems that

phone authenticate itself with Google at some periodicity using

Gmail ID. After this step we filtered out all those packets

which are exchanged with Google server to get exact traffic

pattern for Facebook. Figure 4 shows the traffic pattern onlyfor 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


3/5

Fig. 4. Traffic 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 traffic 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 thesame exercise of collecting traffic 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 find 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 traffic 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

Fig. 6. Traffic Pattern for Skype App in Andriod

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. Traffic pattern of

all the captured packets is shown in Figure 6. Skype uses

heavy cryptographic techniques, so deep packet analysis wasnot 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

filtering 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 difficult

to find packet details.

4) Due to these limitations, it was also not possible to con-

firm 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 TCPbased 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 difficult 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.


4/5

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

Keep-alive messages which are short and frequent, are one

of the main components of background traffic. These keep-

alive 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 configuration 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 config-

urations and choose very conservative values for keep-alive

messages. This knowledge mismatch leads to much higher

frequency of keep-alive messages than actually required. How-

ever 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

timeout values for certain ports as an optimization e.g.

for Googles push service framework [12].

3) 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 suchtimeouts, in such a way that if those applications have

to send messages then those messages can be sent in

one stretch.

4) There is a possibility that a module (as application or

part of platform) can be introduced in future to perform

NAT traversal and firewall 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].

5) IETF BEHAVE working group recommend a timeout

value for 124 minutes for TCP [12] whereas currently

networks are using much smaller values which can prob-

ably be increased in due course of time by Operators.

6) NATs will not be generally needed for IPv6. However

firewall 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.

7) 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 en-

hancements in LTE to handle diverse range of applications,

it would be better that LTE specification itself provide some

mechanism rather than depending on solutions from other

domains.

III . SIMULATION AND RESULTS

Background traffic usually can be classified as light back-

ground traffic and heavy background traffic. Facebook shows

the characteristics for light background traffic and Skype

shows characteristics for heavy background traffic. As seen,

light background traffic for applications such as facebook is

quite sparse, so it does not create much from signaling over-head & battery consumption point of view. However, heavy

background traffic 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 traffic on

LTE networks, we fed the trace shown in Figure 6 into the in

house developed LTE simulator with DRX functionality. Fig

8 and fig 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 configurations.

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


5/5

be 10 seconds, so figure 9 shows total time spent in active

DRX ON & OFF for different DRX configurations.

IV. POSSIBLE SOLUTION DIRECTIONS

As observed from Figure 8 & 9, longer values of connection

release time and longer DRX period can provide battery savingand 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 configurations

which will lead to battery savings.

2) Deep Packet Inspection (DPI) are becoming common

feature in NW. NW can find 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 traffic isgetting generated there can be sudden burst of active

traffic. For example user watching video for some time

and then again background traffic starts. If multiple DRX

configurations are made in advance and either UE or

eNB just signal which DRX configuration will be in

use from now can lead to battery savings.

4) In case of heavy back ground traffic (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 sameamount 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 traffic packets are delay tolerant so

it is possible to aggregate more than one packet at

MAC/RLC level and then sending them together. Withthis it is possible to save battery.

V. CONCLUSION

We have investigated effect of popular applications such

as Facebook, Skype, Email exchange on power saving mech-

anisms available in present day 4G LTE networks. We find

that while Facebook, Email exchange kind of application can

run in energy efficient way due to short and long drx cycle

mechanisms, Skype kind of traffic is very difficult to handle.

To achieve battery saving and fewer signaling overhead, it

is required to enhance the LTE specifications in order to

accommodate the possible directions mentioned in section 4.

0 10 20 30 40 50 60 70 80 90 1000

100

200

300

400

500

600

700

800

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

NumberofIdletoConnectedAttemptsorTimeinMinutes

Idle to Connected Attempts

Idle Time(Minutes)

Connected Time(Minutes)

Fig. 8. Skype performance with respect to Connected to Idle (C2I) release

timer

10 15 20 25 30 35 40 45 500

10

20

30

40

50

60

70

80

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

TimeinMinutes

DRX ON Time (Minutes)

DRX OFF Time (Minutes)

Fig. 9. Skype trace with DRX configuration

REFERENCES

[1] Bontu,C et al. DRX mechanism for power saving in LTE IEEE Commu-nications Magazine, Volume 47, Issue 6, June 2009 pp: 48-55

[2] Kuo-Chang Ting et al.Energy-Efficient DRX Scheduling for QoS Traffic

in LTE Networks IEEE 9th International Symposium on Parallel andDistributed Processing with Applications (ISPA), 2011

[3] R2-114303, Analysis of background traffic characteristics, Ericsson, ST-Ericsson

[4] Hossain Fallaki et al Diversity in smartphone usage 8th Internationalconference on mobile systems MobiSys 10, June 2010.

[5] Gregor Maier et al First look at mobile handheld device traffic,11th

international conference on Passive and active measurement, 2010.[6] Hossain Falaki et al A First Look at Traffic on Smartphones 10th annualconference 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 Smart-

phone, 3GPP RAN2 #75Bis October 2011[9] R2-115431 Samsung Analysis of Skype application in Android Smart-

phone, 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 ACMSIGCOMM 2011, August 2011

[13] Apple Push Notification Service. www.support.apple.com/kb/HT3576[14] Trusted Source www.trustedsource.org

an investigation into traffic analysis for diverse data applications on smartphones

Documents