layeriphonewifi

AnatomizingApplicationPerformanceDifferencesonSmartphonesJunxianHuangUniversityofMichiganhjx@eecs.
umich.
eduQiangXuUniversityofMichiganqiangxu@eecs.
umich.
eduBirjodhTiwanaUniversityofMichigantiwana@eecs.
umich.
eduZ.
MorleyMaoUniversityofMichiganzmao@eecs.
umich.
eduMingZhangMicrosoftResearchmzh@microsoft.
comParamvirBahlMicrosoftResearchbahl@microsoft.
comABSTRACTTheuseofcellulardatanetworksisincreasinglypopularduetothewidespreaddeploymentof3Gtechnologiesandtherapidadoptionofsmartphones,suchasiPhoneandGPhone.
Besidesemailandwebbrowsing,avarietyofnetworkapplicationsarenowavailable,renderingsmartphonespotentiallyusefulsubstitutesfortheirdesk-topcounterparts.
Nevertheless,theperformanceofsmartphoneap-plicationsinthewildisstillpoorlyunderstoodduetoalackofsystematicmeasurementmethodology.
Weidentifyandstudyimportantfactorsthatimpactuser-perceivedperformanceofnetworkapplicationsonsmartphones.
Wedevelopasystematicmethodologyforcomparingthisperfor-mancealongseveralkeydimensionssuchascarriernetworks,de-vicecapabilities,andservercongurations.
Toensureafairandrepresentativecomparison,weconductcontrolledexperiments,in-formedbydatacollectedthrough3GTest,across-platformmea-surementtoolwedesigned,executedbymorethan30,000usersfromallovertheworld.
Ourworkisanessentialsteptowardsun-derstandingtheperformanceofsmartphoneapplicationsfromtheperspectiveofusers,applicationdevelopers,cellularnetworkoper-ators,andsmartphonevendors.
Ouranalysisculminateswithasetofrecommendationsthatcanleadtobetterapplicationdesignandinfrastructuresupportforsmartphoneusers.
CategoriesandSubjectDescriptorsC.
2.
1[NetworkArchitectureandDesign]:Wirelesscommuni-cation;C.
4[PerformanceofSystems]:Performanceattributes;C.
4[PerformanceofSystems]:Measurementtechniques;D.
2.
8[Metrics]:PerformancemeasuresGeneralTermsExperimentation,Measurement,PerformancePermissiontomakedigitalorhardcopiesofallorpartofthisworkforpersonalorclassroomuseisgrantedwithoutfeeprovidedthatcopiesarenotmadeordistributedforprotorcommercialadvantageandthatcopiesbearthisnoticeandthefullcitationontherstpage.
Tocopyotherwise,torepublish,topostonserversortoredistributetolists,requirespriorspecicpermissionand/orafee.
MobiSys'10,June15–18,2010,SanFrancisco,California,USA.
Copyright2010ACM978-1-60558-985-5/10/06.
.
.
$10.
00.
KeywordsSmartphone,3Gnetwork,Applicationperformance,Performancecomparison,Celluardatanetworkperformance1.
INTRODUCTIONAsofthethirdquarterof2009,globalsmartphoneshipmentsreached41.
4millionunitsrepresentingabout15%ofthetotalmo-bilephonemarket[3].
Itisexpectedthatinthenextfewyearssmartphonesaleswillcatchupwiththesalesofregularphones.
Vendors,suchasResearchinMotion,Samsung,Palm,HTC,andApple,offeravarietyofsmartphonesequippedwithincreasinglyfasterCPUsandlargermemory,thoughstilllaggingbehinddesk-toporlaptopsystems.
Withaccesstovarioushigh-speed3Gnet-works,suchasEVDOandUMTS,theyarepowerfulenoughtorunmodernoperatingsystemsandsophisticatednetworkapplicationssuchaswebbrowsing,email,andstreamingmedia.
UnliketraditionalInternet-basedapplications,whoseperfor-manceismostlyconstrainedbythewirednetwork,networkappli-cationperformanceonsmartphoneswithlimitedphysicalresourcesalsoheavilydependsonfactorsincludinghardwareandsoftwareonthephoneaswellasthequalityandloadofwirelesslink.
Un-derstandingtheapplicationperformanceonsmartphonesisimpor-tantforthepurposeofassistingconsumersinchoosingcarriersandphonesandguidingapplicationdevelopersindesigningintelligentsoftware.
Moreover,cellularnetworkoperatorsandsmartphonehardwareandsoftwarevendorscanusethisknowledgetooptimizenetworksandphonesforbetterend-userexperiences.
Similarly,contentproviderscanleveragethisknowledgetobettercustomizecontentformobileusers.
However,thistaskisquitechallengingsincetheperformanceofnetworkapplicationsonsmartphonesispoorlyunderstoodthusfar,duetoalackofasystematicapproachforcontrolledexperimentsandcomparativeanalysis.
Webelievethisworkllsthisgap.
Wefocusondevelopingsystematicmethodologyformeasuringandanalyzing3Gnetworkperformanceaswellassmartphoneap-plicationperformance.
Wemakeitrelevanttoendusersbystudy-ingrealapplicationsdirectlyonthephoneplatforms.
Ourap-proachdiffersinherentlyfrommostpreviousworkofusinglaptopsequippedwith3Gdatacardsinthreeways:(1)Wemeasuretheperformanceofapplicationsratherthanthatofthelow-levelproto-cols.
Priorworkhasshownthatapplicationperformanceoftensig-nicantlydeviatesfromprotocolperformance[24].
Wetargetthepervasivewebbrowsing,streamingvideo,andVoIPapplicationsthatmostend-userscareabout;(2)Wemeasureapplicationper-formanceonseveralcommonmobiledevices.
Applicationperfor-mancevarieswidelyacrossdevicesduetodifferencesinhardwareandsoftware,necessitatingdirectexperimentationonsmartphonesinsteadofonlaptopswithwirelesscards;(3)Westudytheapplica-tionperformanceunderreal-worldscenariosandquantifytheper-formanceofwebbrowsingbyevaluatingcommercialwebsitesinadditiontolocally-constructedoneswithreplicated,realwebcon-tentunderourcontrol.
Thelattersetuphelpsdissectandanalyzetheindividualfactorsthatcontributetotheoverallwebbrowsingperformance.
Toovercomethelimitationofasinglevantagepointforlocallyconductedmeasurements,wedesignanddeployacross-platformmeasurementtool,called3GTest,tomeasurenetwork-levelper-formance,usingbasicmetricssuchasthroughput,roundtriptime(RTT),retransmissionrate,etc.
attractingmorethan30,000usersallovertheworld,providingarepresentativedatasetonthecurrent3Gnetworkperformance.
3GTestenablesustocarryoutlocalex-perimentsinformedbyrealistic3Gnetworkconditionsacrossdi-verselocationsandnetworkcarriers.
Asfarasweknow,3GTestistherstsuchcross-platformtoolavailablethatcomprehensivelycharacterizes3Gnetworkperformance,andourdatasetisalsouniqueinthatregard.
Inadditiontosheddinglightontheoverallapplicationandnet-workperformance,weperformdetailedanalysistoidentifyandisolatefactorsthatimpactuser-perceivedperformancetohelpcar-riers,phonevendors,contentproviders,andapplicationdevelopersgaininsight.
Forexample,forcarriers,weinfervariousnetwork-levelproblems,e.
g.
,highlatencyorhighlossrate,whichtheycandirectlytakeactionon.
Forphonevendors,weidentifyper-formancebottlenecksonthedevicesorissuesassociatedwiththecontent.
Theseissuescanberesolvedeitherindependentlyorbycooperatingwithcontentproviders.
Andforapplicationdevelop-ers,weevaluatefactorssuchastheoverheadofHTMLrenderingandJavascriptexecutiongivenaparticularsoftwareconguration.
Wecomprehensivelystudythe3Gnetworkandapplicationper-formanceforallfourmajorU.
S.
wirelesscarriersincludingAT&T,Sprint,Verizon,andT-Mobile.
Wechoosepopulardevicesinclud-ingiPhone,AndroidG2fromHTC,andWindowsMobilephonesfromPalm,HTC,andSamsungforcarryingoutexperiments.
Ourresultsshowthattheirperformancevariessignicantlyacrossnet-workapplications.
Infact,evenforthesamenetworkapplicationsuchaswebbrowsing,certaintypesofphonesconsistentlyoutper-formothersduetothedifferencesinfactorssuchasdownloadingbehavior,customizedcontents,andpagerendering.
Theapplica-tionperformancealsoheavilydependsonpropertiesofcarriersin-cludingDNSlookup,RTT,andlossrate.
Wesummarizeourmainobservationsfromextensiveexperimen-tation:1.
Thefourcarrierswestudieddemonstratedistinctcharacteris-ticsinnetworkperformanceintermsofthroughput,RTT,re-transmissionrate,andtime-of-dayeffect.
Forexample,com-paredwithT-MobileandAT&T'smedianofTCPretrans-missionrateof0%,SprintandVerizonhaveahighermedianvalueof0.
7%.
2.
TCPthroughput,RTT,andretransmissionratevarywidelyevenforasinglecarrierinmeasurementtakenatdifferenttimesandlocations,e.
g.
,downlinkthroughputrangesfrom50kbpsto4MbpsforAT&T,withthemedianvalueofabout1Mbps.
3.
Thewirelessdelayinthe3Gnetworkdominatesthewholenetworkpathdelay,e.
g.
,latencytotherstpingablehopisaround200ms,whichisclosetotheend-to-endPinglatencytolandmarkserversdistributedacrosstheU.
S.
4.
Besidesnetworks,devicesheavilyinuenceapplicationper-formance.
Giventhesamecontentandnetworkcondition,differentdevicesexhibitvastlydifferentwebpageloadingtime,e.
g.
,thepageloadingtimeofSamsungSCHi760isconsistentlytwicethatofiPhone.
5.
MobiledevicescanbenetfromnewcontentoptimizationtechniqueslikethedataURLscheme,e.
g.
,pageloadingtimeforGPhonecanimproveby20%inourexperiments,despiteitsalreadygoodperformancecomparedtootherdevices.
Thepaperisorganizedasfollows.
§2coversrelatedwork.
In§3,weproposeourmethodologyforexperiments,followedbydetailsoftheexperimentalsetupin§4.
In§5,wepresent3Gnetworkcharacterizationandthenfocusonwebperformancein§6.
WeevaluatetheperformanceofstreamingvideoandvoiceoverIPin§7,andconcludein§8.
2.
RELATEDWORKOurworkisinspiredbytheNetdiffsystem[17],whiches-tablishedabenchmarkforcomparingperformanceofdifferentISPs.
Inourresearch,weattempttoestablishanequivalentbench-markforcomparingnetworkapplicationperformanceonsmart-phones.
Althoughsomeonlinecomparisonsareavailable,suchasSpeedtest.
net[7]andFCC'sbroadbandtest[4],whichmeasurethroughputandlatencyin3Gnetworks,3GTestcoversamorecom-prehensivesetofmetrics,includingDNSlookup,pingtothersthop,TCPhandshake,andHTTPrequesttolandmarkservers.
Tanetal.
carriedoutasimilarmeasurementstudyonmultiplecommer-cial3Gnetworks[20].
However,theirstudyislimitedtooneloca-tion(HongKong)andafewdevices.
Comparedwiththeirstudy,ourworkcoverssignicantlymoreusersfrommanydifferentloca-tions.
Therehavebeenseveralstudiesfocusingonmobileusersfromtheperspectiveofapplications,suchas[21]whichcharacterizedtherelationshipbetweenusers'applicationinterestsandmobil-ity,and[9]whichexaminedthepossibilityofgeolocatingIPad-dressin3Gnetworks.
Otherrelatedmeasurementworksofcellulardatanetworksincludeastudyoftheinteractionbetweenthewire-lesschannelsandapplications[16],aninvestigationofapplication-awareaccelerationtoimproveapplicationperformance[24],aper-formancestudyofmultimediastreaming[12],andperformanceanalysisofTCP/IPover3Gnetworkwithrateanddelayvaria-tion[11].
Ourworkcomplementstheseworkswithdifferentfocusandmethodology.
Fromtheperspectiveofmeasurementmethodology,our3GTesttoolisamongtheearliestcross-platform3Gnetworkperformancecharacterizationtoolsforsmartphonescoveringadiversesetofper-formancemetrics,eventhoughtheideaoftakingmeasurementsfromvoluntaryusersisnotnovel.
Forexample,Netalyzr[5]isonesuchtoolfocusingondesktopenvironment.
Unlikepreviousstud-ies,e.
g.
,[16,10,14],whichperformmeasurementsondesktoporlaptopsystems,relyingoncellularnetworkdatacardsorphonestetheredthroughUSBasamodem,weevaluateapplicationper-formancedirectlyusingphonesasthemeasurementplatform,thusmoreaccuratelyreectingtheactualuserexperience.
Comparedtomanypreviousworks,wedonotrelyonpropri-etarydatafromcarriersandmostlytakeablack-boxmeasurementapproachbyexaminingperformanceattheapplicationandnetworklayerswithoutaccessingdetailedinformationofwirelesschannels(e.
g.
,[16])ortheinternalstateofcellulardatanetworks(e.
g.
,[23]).
Thisthereforepresentsaninterestingchallengeofinferringthebot-tleneckofobservedapplicationperformance.
Wearguethatthelimitationofreducedvisibilityintotheinnerworkingofthe3Gnetworkdoesnotpreventusfromachievingthegoalofeffectivelycomparingnetworkandapplicationperformanceacrossdifferent3Gcarriersandunderstandingtheeffectofmajorfactors.
OurworkisbuiltuponnumerouspreviousTCPstudiesforcellu-lardatanetworkswhichaimtounderstandthebehaviorofTCPus-ingcross-layermeasurementtechniques[18],tomodelmulti-rateandmulti-userbehavior[13],andtoimprovetransportlayerforwirelesswide-areanetworks[22].
Thesestudiesexposethelimi-tationsofexistingTCPdesigns,someofwhicharealsoconrmedbyourwork.
3.
METHODOLOGYInthissection,wepresentourmethodologyformeasuringnet-workandapplicationperformanceover3Gnetworks.
InspiredbypreviousworkintheInternet,e.
g.
,Netalyzr[5],whichcollectsmeasurementdatafromvolunteers,wedevelopacross-platformmeasurementtoolusedbytensofthousandsofusersontheirsmart-phonestobuildacomprehensivedatasetforcellularnetworks.
Byanalyzingtheperformanceofweb,video,andVoIPapplications,weexaminetheeffectsofvariousfactorsontheoverallapplicationperformance.
Unlikemostpreviousworks,wedirectlymeasureapplicationperformanceondevicesthatconsumersreallyusewith3GserviceprovidedbyfourmajorcellularcarriersintheU.
S.
,thishelpsusunderstandtheclientsidefactorsandtheirimpactonapplicationperformance.
Thenoveltyofourmeasurementmethodologystemsfromourapproachofapproximatelyreplicatingthe3GnetworkconditionforcontrolledexperimentsusingWiFitoenablerepro-ducibility,andisolatingtheimpactofeachfactor.
Thesetechniquesarenon-trivialgiventhecomplexityofmobiledevicesandnetworkenvironment,andessentialforeliminatinginteractionacrossfac-tors.
3.
1MeasuringnetworkperformanceWerstdescribethemetricsweuseforevaluatingnetworkper-formanceandhowwecomputethem.
3.
1.
1MetricsTocharacterizenetworkperformance,weuseTCPthroughput,downlinkRTT,retransmissionrate,localDNSlookuptime,TCPhandshaketime,andPinglatencytotherstresponsiveIPhopasourmetrics.
TCPisofparticularinterest,sincemostnetworkap-plicationsuseTCP.
AnapplicationsessionusuallyrequiresDNSlookup,andeveryTCPconnectionbeginswithaTCPhandshake.
Hencethesetwofactorscontributeheavilytouser-perceivedper-formanceofmanynetworkapplications.
Pinglatencytotherstresponsivehopprovidesanestimateofthelatencyofthewirelesshop.
3.
1.
23GTestWedevelopedacross-platformtoolnamed3GTestformeasuringcellularnetworkperformance.
ItrunsseveralexperimentstocollectmeasurementssuchasTCPthroughput,DNSlookupdelay,TCPhandshaketime,andPinglatency.
IntheTCPthroughputexperi-ment,dataistransferredbetweenthephoneandaserverconnectedtotheInternetforatimeduration.
PackettracesarecollectedattheserversidetocalculateTCPdownlinkanduplinkthroughput,RTT,andretransmissionrate.
FortheDNSexperiment,3GTestsendsDNSrequeststoresolvealistofselectedpopulardomainnames.
BytuningthesizeofthelistandlookingupeachDNSnametwice,weensurethenamesarehighlylikelycachedatthelocalDNS(LDNS)serverincarriernetworksbutnotonthephonebasedonobservedlatencies.
ThisispossiblesincecomparedtothephonetheLDNSservertypicallyhasalargerDNScache.
TomeasureTCPhandshake,3GTestsendsTCPconnectrequeststoseverallandmarkserverssparselydis-tributedacrosstheU.
S.
Tocharacterizepinglatency,ourtoolpingswww.
google.
comwithincreasingTTLvaluesstartingfrom1andrecordstheIPaddressandcorrespondingRTT.
3GTestalsopingsthelandmarkserverstoobtainthedelaydistributiontodi-verseInternetlocations.
Wehavemade3GTest(http://www.
eecs.
umich.
edu/3GTest/)publiclyavailable,whichallowsustocharacterize3Gnetworkperformanceinmultiplecellularcarriersatdiverseloca-tionsoveranextendedduration.
3.
1.
3AnalysismethodologyWecalculateRTTandTCPretransmissionratefromservercol-lectedpackettrace.
WefollowthestandardmethodtoinferRTTsfromtracesatthesender.
Atanygiventime,wepickonedatapacketanditscorrespondingACKpackettocomputeoneRTTsample.
WetakeonesampleperTCPwindowsothattheaverageRTTwillnotbeskewedbythewindowsize.
Topreventretransmis-sionfrominatingRTTestimation,wediscardanRTTsampleifthereisanyretransmissioninthesamewindow.
WethencomputetheaverageRTTofallthesamplesofaTCPconnection.
3.
2MeasuringwebbrowsingperformanceWebbrowsingisoneofthemostpopularsmartphoneappli-cations.
Theprocessofvisitingawebpagecanbequitecom-plexgiventhedynamicnatureofthecontentoftengeneratedfromJavascript,resultinginmultipleconcurrentTCPconnections.
Con-tentcanalsobecustomizedbasedonmobiledeviceandcarriernetwork.
Webbrowsingperformancedependsonvariousfactors,e.
g.
,DNSlookuptime,TCPhandshaketime,TCPtransfertime,Javascriptexecutiontime,andcontentsize.
Tostudytheeffectofthesefactors,wecarefullydesigncontrolledexperimentstoma-nipulateasinglefactoratatimewhilekeepingothersthesame.
Werstdescribethemetricsusedtoevaluatewebbrowsingper-formance,followedbythecontrolledexperimentstomeasurethesemetrics.
3.
2.
1MetricsPageloadingtime:ThetimebetweentherstDNSpacketandthelastdatapacketcontainingpayloadfromtheserverduringapageloading.
Itreectstheoverallperformanceperceivedbyauser.
Notethatabrowserneedstofurtherparseandrenderawebpageafteritisloaded.
Thisadditionalprocessingmaynotbefullyincludedinpageloadingtimeduetoalackofvisibilityofthebrowserinternals.
Nonetheless,thisisstillakeyindicatorofuser-perceivedperformancewhenloadingawebpage.
Javascriptexecutionspeed:ManywebpagescontainJavascripts,andhenceJavascriptexecutionspeedhassignicantimpactonpagerenderingtime.
Pagesize:Thetotalnumberofuniquebytesdownloaded.
Itcanbeusedtocomputeaveragethroughputandtodetectcontentvari-ationandcustomization.
Wefoundthatinrealwebbrowsing,eventhesameURLcanhavedifferentpagesizeswhenaccessedfromdifferentplatforms.
WecopewiththiseffectbytakingsnapshotsofURLsandreplicatetheircontentonourlocalwebserver.
Browserconcurrency:Mostmodernbrowserssupportconcur-rentTCPconnectionstoasinglewebdomain.
Themaximumnum-berofconcurrentTCPconnectionstoadomainvariesacrossdif-ferentbrowsers.
Usually,higherconcurrencyenablesbetterband-widthutilizationwhichinturnleadstoshorterpageloadingtime.
DNSlookuptime:AbrowsersometimesneedstolookuptheIPaddressofadomainnamebeforeestablishingaTCPconnectionwiththewebserver.
Sincethecontentofawebpagecanbehostedinmultipledomains,abrowsermayhavetoperformaDNSlookupforeachdomain.
TCPhandshaketime:EachTCPconnectionstartswithathree-wayhandshakeduringwhichnodataistransferred.
MoreTCPhandshakesforasinglepageloadingoftenleadtolargerpageload-ingtime.
TCPidletime&transfertime:GivenaTCPconnection,anidleperiodisdenedtobeaperiodofatleastTsecondwithnonetworkactivity.
Theremainingtimeperiodswithintheconnectionaretransferperiods.
Anidleperiodusuallycorrespondstothelocalprocessingdelayorserverprocessingdelay.
GiventhelimitedCPUpowerandmemoryonsmartphones,theTCPidletimeislikelytobedominatedbylocalprocessingdelay,e.
g.
,betweenthereceiptofaresponseandtransmissionofthenextrequest,oftencausedbyHTMLrenderingandJavaScriptexecution3.
2.
2ControlledexperimentsWecreatealistofpopularURLsfrom[1].
Thesewebsitesarevisitedusingsmartphonesvia3Gnetworks.
Fromthecollectedpackettrace,weinfervariousmetricssuchaspageloadingtime.
Tostudytheeffectofeachfactorinuencingthewebbrowsingperformance,wehoststaticcopiesofthesepopularURLsonourlocalwebserver.
ThecontentisreplicatedtoensurethatallthephonesdownloadthesamecontentandallHTTPrequestsaresenttothelocalserver.
Tocontrolthenetworkconditions,weuniformlyuseWiFiacrossallphoneswhilevaryingonefactoratatime.
TheWiFilinkislightlyloadedandhasstablethroughputandRTT.
Toproducenetworkconditionscomparableto3G,wearticiallyin-troducedelayandpacketlossatourserver.
Westudytheimpactofthefollowingfactorsonwebbrowsingperformance:Impactofnetwork:Tostudytheeffectofnetworkconditionsonpageloadingtime,wevarytheRTTandlossrateonourserver.
Impactofconcurrency:Tostudytheeffectofconcurrency,wecontrolthemaximumnumberofconcurrentTCPconnectionstoawebdomainontheserverside.
Becauseaphonealsolimitsthemaximumnumberofconcurrentconnectionsperdomain,wecreateaspecialwebpageinwhicheachwebobjectishostedinauniquedomainonthesamewebserver.
Thiseffectivelyallowsustobypasstheconcurrencylimitimposedbythephones.
Notethatthisisnecessaryaswedonothavethepermissiontodirectlymodifytheconcurrencylimitonthephone.
Impactofcompression:Tostudythetradeoffbetweennetworkoverheadandcomputationoverhead,wecongureourwebserverintotwomodes,oneusescompression,whiletheotherdoesnot.
Wecomparethepageloadingtimeunderthesetwomodes.
ImpactofJavascriptexecutionspeed:ToevaluateJavascriptexecutionspeedondifferentphones,weuseabenchmark[8]con-sistingof26differentJavascripts.
ThebenchmarkishostedonourwebserverandaccessedbyphonesviaWiFisothatthedownload-ingtimeisnegligiblysmall.
WemeasurethetotalexecutiontimeoftheseJavascripts.
ImpactofdataURLscheme:WealsostudytheeffectofthedataURLscheme[15],arecently-proposedmobilewebpagedesigntechniques.
WecomparethetimetoloadawebpageconstructedusingandwithoutusingthedataURLscheme.
3.
2.
3AnalysismethodologyNowwedescribehowtoanalyzethetracescollectedfromcon-trolledexperimentstocomputethedesiredmetrics.
WecalculatethepageloadingtimeofeachURLasdenedin§3.
2.
1andtheaveragepageloadingtimeofalltheselectedURLs.
TomeasureJavascriptexecutiontime,wemodifytheJavascriptstodisplaytheirexecutiontimewhentheirexecutionnishes.
Weusetheav-erageconcurrencyasameasureofbrowserconcurrency.
Theav-erageconcurrencyofapageloadingiscalculatedbydividingthetotaldurationofalltheTCPconnectionsbythepageloadingtime.
ForeachTCPconnection,TCPhandshaketimeiscalculatedasthetimebetweentherstSYNandSYN-ACKpackets.
TCPidletimeismeasuredbyscanningtheconnectionfordurationsofmorethanTsecondsofnonetworkactivity.
TshouldbelargerthanthemaximumRTTvaluesandwewilldiscussthechoiceofTin§4.
TCPtransfertimeistherestfortheconnection.
WealsocalculatetheresponsetimeofalltheDNSlookupsTdns.
Sinceeachwebbrowsingsessionoftenconsistsofmultiplecon-currentTCPconnections,toestimatethecontributionofeachfactortotheoverallperformance,welogicallyserializeallDNSlookupsandTCPconnections.
Thisispossibleformobilewebbrows-ingsincenoHTTPpipeliningisobservedonanyphones.
Af-terserialization,wegetatotaltimeTtotalwhichisthesumofeachconnection'sduration.
AssumingtheactualpageloadingtimeisTtotal,thenormalizedDNSlookuptimeTdnsiscalculatedasTtotalTdns/Ttotal.
ThismetricshowstheoverallweightofDNSlookupintheactualpageloadingtime.
ThenormalizedTCPhand-shaketime,TCPidletimeandTCPtransfertimearecalculatedinasimilarway.
4.
EXPERIMENTALSETUPInthissection,weintroducetheplatformsusedforourexper-iments,thecross-platformmeasurementtool(3GTest)thatwede-velopedandwidelydeployed,andtheactualconditionsandparam-eterschosenfortheexperimentsoutlinedin§3.
4.
1PlatformsTable1liststhedevicesusedandcarriersstudiedinthiswork.
WestudiedfourmajorcarriersintheU.
S.
,AT&T,Sprint,Veri-zon,andT-Mobile.
TheysplitbetweenUMTS/HSPA(AT&TandT-Mobile)andEVDO(SprintandVerizon).
AT&Thasthehighestadvertiseddownlinkanduplinkdatarates.
Theactualdataratesthatausercanattaindependonmanyfactors,suchassignalstrength,location,andbackgroundtrafc.
Oneofourgoalsistounderstandhowtheactualdataratesmatchtheadvertisedonesandwhichfac-torshavethebiggestimpactonactualdatarates.
Tomeasureuser-perceivedperformanceonsmartphones,weconductedcontrolledexperimentsonvepopulardeviceslistedinTable1.
Wealsousedafewdesktopcomputersaswebservers.
Thesedesktopsareconnectedwithhigh-speedethernetsothattheyareunlikelytobecomethebottleneck.
TheyhaveIntelCore2Duo2.
26GHzprocessorsand2GBmemory,runningUbuntu9.
10andFirefox3.
5.
4.
23GTestTomakeourstudyrepresentativeacrossmultiplelocationsandcarriers,wedevelopedacross-platformmeasurementtool3GTest[6]forthreemobileplatforms:iPhone,AndroidandWin-dowsMobile.
3GTestconsistsofseveraltypesofexperimentsessentialtocharacterizenetworkperformance,includingTCPthroughput,DNSlookup,TCPhandshaketolandmarkservers,pingtotherstresponsivehop,pingtolandmarkservers,etc.
ForReferredtoasiPhonePalmSamsungG2HTCCarrierAT&TSprintVerizonT-MobileAT&TNetworkUMTSEVDOEVDOUMTSUMTSAdvertisedDownlink(Mbps)0.
7-1.
70.
6-1.
40.
6-1.
40.
6-1.
00.
7-1.
7AdvertisedUplink(Mbps)0.
5-1.
20.
35-0.
50.
5-0.
80.
3-0.
70.
5-1.
2VendorApplePalmSamsungHTCHTCDeviceiPhoneTreo800wSCHi760AndroidG2TyTnIIMemory(MB)12812864192128Processor(ARM)11761136920T1136EJS1136EJSCPUfrequency(MHz)620333400528400OSiPhoneOS2.
1WindowsMobile6.
1WindowsMobile6.
1Android1.
6WindowsMobile6.
1BrowserSafariIEIEBrowserAppIETable1:Devicespecicationsand3Gnetworkcarriers§FigureDescriptionCategory5.
1Figure1(a)(b)(c)(d)3GTestdownlink,uplinkperformanceTCP(3GTest)5.
1Figure1(e)(f)(g)(h)3GTestPing,DNS,TCPhandshakePing,DNSlookup,TCPhandshake(3GTest)5.
2Figure23GTestusertimepatternUsertimepattern(3GTest)5.
2Figure3(a)(b)(c)TCPdownlinkperformanceandtimeofdayeffectTCPandusertimepattern(3GTest-Local)6.
1Figure4(a)(b)Pageloadingtimevs.
RTT/retransmissionrateTCPperformancevs.
webperformance6.
2Figure4(c)ImpactofparallelismParallelisminconcurrentTCPconnections6.
3Figure4(d)ImpactofcompressionContentcompression6.
4Figure5JavaScriptExecutionClientcapability6.
5Figure6DataURLschemeContentoptimization6.
6Figure7Timebreakdownforsimplevs.
content-richURLs3Gwebbrowsing7.
1Figure8ContentsizeandvideotimelineStreamingvideo7.
2Figure9VoIPtimelineVoIPTable2:SummaryofexperimentalresultsTCPthroughputexperiment,3GTestconductsalengthof20sec-ondsofdatatransferbetweenthephoneandourserver.
Durationof20secondsischosensothatenoughpacketsaretransferredbe-tweenphoneandserveranduserswillnotsufferfromlongwait-ingtime.
Wechose80domainnamesforDNSexperimentsothatDNSresolutionresultsarenotlocallycachedonthephonesbutarecachedonLDNSserver.
ForTCPhandshakeandPinglatencyex-periments,wechose20landmarkserversfromPlanetLabsparselydistributedacrosstheU.
S.
Resultsfortheseexperimentsaresentbacktoourserverbefore3GTestterminates.
Wehavebeenusing3GTesttocollectdataforseveralmonths,duringwhichtensofthousandsofusersfromvariouscountrieshaveinstalledandrun3GTest.
ThedatasetusedinthispaperwascollectedbetweenAugust27,2009toDecember1,2009,contain-ing68,908runsof3GTestwith30,105uniqueusersintotal.
Inthispaper,weonlyanalyzedthe3GnetworkdatacollectedinsidetheU.
S.
(50%oftheentiredataset).
4.
3NetworkperformanceexperimentalsetupTomeasurethenetworkperformanceoveralongterm,wecre-atedaninternalversionof3GTest-LocalandinstalleditonthesmartphoneslistedinTable1.
3GTest-LocalismodiedtorecordthesignalstrengthontheSamsungandPalmphones.
3GTest-Localcontinuallyconductsmeasurementsevery10minutestocollectoneweek'sdata(excludingweekends)inAnnArbor,MI.
Wemakesurethatthephonesareplacedatthesamelocationwithexcellentsig-nalstrengthduringtheentiremeasurementstudy.
Sincethedataiscollectedcontinuallyforalongperiodoftime,itcanbeusedforcharacterizingthetime-of-dayeffect.
4.
4WebbrowsingexperimentalsetupForwebbrowsingexperiments,wepickedalistof20popularandrepresentativeURLsincludingsearchengines,emails,onlinemaps,socialnetworkingwebsites,etc.
FormostoftheURLs,weusedtheirmobileversion.
Tofacilitaterepeatedexperiments,wewroteaprogramtoinvokebrowsertovisiteachURLinturnwithanintervalof120seconds.
Suchintervalisexpectedtobelargeenoughtocompletethepagedownload.
WeusedApache2.
0HTTPserverforhostingthereplicatedwebsites.
WecollectedpackettracesoniPhoneandGPhoneusingtcpdumpandonWin-dowsMobilephonesusingnetlog.
WeveriedthattheCPUuti-lizationcausedbytracecollectionisunder5%.
Alltheexperimentswererepeated10times.
Tointroducearticialdelayandloss,weranauser-levelprogramontheserver.
ThisprograminterceptsallpacketsdestinedtoaparticularIPaddressandinjectsdelayandrandompacketloss.
Wecontrolledlossratevaluesfrom0%to10%andRTTvaluesfrom0msto800ms.
ThesevaluescovertheentirerangeoflossrateandRTTvaluesobservedin3Gnetworksfromour3GTestdataset.
Wecontrolledthemaximumconcurrentconnectionsbycong-uringtheApacheserverwiththehelpofthempm_prefork_module.
Weconstructedawebpagewith30embeddedobjectsinthemainHTMLpagetoinferthemaximumnumberofconcurrentconnec-tionsallowedbyaphonetoonewebdomain.
Forconcurrencyexperiments,weusedRTTof400msandlossrateof0%.
Theyarethemedianvaluesfromthe3GTestdataset.
Forthecompressionexperiments,weusedSetOutputFilterandBrowserMatchdirectivestospecifywhethercompressionisen-abledforaspecictypeofbrowser.
Wexedlossrateat0%andvariedRTTfrom0msto800ms.
Ourgoalistounderstandwhethercompressionisbenecialunderdifferentnetworkconditions.
ForthedataURLexperiment,weconstructedawebpagewith20images;10ofthemare18KBandtherest10are0.
241KB.
Wecreatedtwoversionsofthiswebpage,onewithlinkstodownloadtheimagesandtheotherwiththeimagesembeddedinthewebpageitself.
WecouldnotcarryoutthisexperimentforWindowsMobilephonessinceIEcurrentlydoesnotsupportthedataURLscheme.
Whenanalyzingthewebbrowsingtraces,wechose1secondasthethresholdtoidentifyTCPidletime.
Inthe3GTestdataset,RTTissmallerthan1secondin99%ofthecases.
Thus,iftherearenonetworkactivitiesfor1secondormore,thephoneshouldbebusywithsomelocalprocessing,e.
g.
,renderingHTMLpagesorexecutingJavascripts.
4.
5VideostreamingexperimentalsetupStreamingvideoisanotherpopularapplicationonsmartphones.
Wemeasurestreamingvideoperformancebyplayinga37:40-minutevideoonthephonesusingaYoutubeapplication.
Fromthecollectedpackettrace,wecalculatethedownloadingsizeofthevideobyaddingupthepayloadsforallthepacketsfromtheservertophonewhileexcludingtheretransmittedpackets.
4.
6VoIPexperimentalsetupWeusedSkypetostudyVoIPperformanceonsmartphonesgivenitspopularity.
ThecurrentversionofSkypecannotbeinstalledoniPhoneOS2.
1orG2.
SoweonlyranSkypeontheSamsungandPalmphones.
Inourexperiments,weplayeda3-minutemusiclefromboththephonesideandtheserverside.
Wecollectpackettraceatthephonesidetocalculatethroughput.
Giventhatdifferentvolumemayleadtodifferentdatasize,throughouttheexperiment,wekeepthevolumetobethesame.
5.
3GNETWORKCHARACTERIZATIONTofullyunderstandtheunderlyingfactorsaccountingfortheob-servedperformanceofnetworkapplications,werstfocusonchar-acterizingtheperformanceofcurrentcommercial3Gnetworks.
Twodatasetsareusedforthispurpose,onefrom3GTest(Figure1)andtheotherfrom3GTest-Local(Figure3).
Toverifytherep-resentativenessoftheresultsfrom3GTest-Local,wecomparethedatarangesofthemetricsstudiedinbothdatasets.
Asexpected,thedatarangesfrom3GTest-Localarewithinthosefrom3GTest.
5.
1ComparisonacrosscarriersFigures1(a)illustratesmeasuredTCPdownlinkthroughput.
GivenstableTCPthroughputisroughlyinverselyproportionaltoRTTandtothesquarerootofpacketlossrate[19],wealsoanalyzeRTTandretransmissionrate.
InFigure1(b),allcarriersshowcom-parableRTTdistributions,withT-MobileshowingslightlylargerRTTvaluesandcorrespondinglylowerdownlinkTCPthrough-put.
VariousreasonscontributetolargeRTTin3Gnetworks,e.
g.
,queueingdelaysatthebasestationorotherinternalnodes,suchasRNC,SGSN,andGGSNinUMTSnetworks.
Westudythisinmoredetailsin§5.
2.
LargeRTTsmayalsobeduetopacketlossrecoveredthroughlinklayerretransmission,whichwedonothavedirectinformationabout.
Figure1(c)plotsmeasuredTCPuplinkthroughput.
Unlikedownlinkthroughput,AT&TandT-MobilehaveloweruplinkthroughputcomparedwithSprintandVerizon.
OneofthereasonscouldbethelackofsupportforUMTS/HSUPAonthephonesusedforAT&TandT-Mobile.
EventhelatestversionofiPhone3GSdoesnotclaimtosupportHSUPA.
ThemedianuplinkthroughputforAT&TandT-Mobilerangesfrom200kbpsto300kbps,whilethatforSprintandVerizonisaround400kbps.
Figure1(d)showsthatVerizonandSprintexhibitslightlyhigherTCPretransmissionrate,matchingobservationsfromourlocalex-periments.
Onaverage,AT&T'sdownlinkthroughputoutperformsthatoftheothercarriersduetoitsrelativelylowerRTTandlossrate.
ThemedianofTCPdownlinkthroughputforallcarriersrangesfrom500kbpsto1Mbps.
MedianRTTvariesfrom300msto500ms,suggesting400msisarepresentativedelayvaluetoemulate3Gnetworks.
AT&TandT-Mobilehaveamedianretrans-missionrateof0%,whilethatforSprintandVerizonis0.
7%.
Figures1(e)&(f)showthatPinglatencytotherstresponsivehopisclosetothattolandmarkservers,suggestingthattherstresponsivehopconsistingof3Gwirelesslinkcontributestomostofthedelayalongtheend-to-endnetworkpath.
NotethatPingla-tencytotherstresponsivehopactuallyreferstotherstIPhoprespondingtoICMPprobing.
ForAT&TandT-Mobile,therstIPhop,whenTTLissetto1,doesnotrespondinmostcases.
OnlythesecondIPhopreplieswithaprivateIPaddress.
ForSprintandVerizon,therstIPhopdoesreplywithapublicIPaddress.
Themedianlatencytotherstresponsivehoprangesfrom150msto200ms,whilethattolandmarkserversisbetween180msand250ms.
WeobservethatboththePinglatencyandTCPhandshaketimearesmallerthanRTTvaluesmeasuredinTCPdownlinkex-periments.
Figure1(g)showsDNSlookupperformance.
Wedesigntheex-perimentinawaythatallDNSlookupsarecachedattheLDNSserverbutnotlocallyonthephone(§4.
2).
ThisallowsustomoreaccuratelyestimatethedelaytotheLDNSservers.
TheLDNSserversstudiedtendnottorespondtoICMPpackets,makingitchallengingtodirectlymeasurethenetworkdelaybetweenthephoneandLDNSserver.
Fromtheresults,wefoundthatallcar-riersexhibitsimilartrendwithmedianvaluescloseto200ms.
GiventhattheDNSlookupdelayisalreadyclosetoPinglatencytotherstresponsivehop,thereislimitedroomforimprovingDNSlookupperformance.
AsshowninFigure1(h),themedianofTCPhandshakedelayrangesfrom160msto200ms,closetothePinglatencytotherstresponsivehopinFigure1(f).
WealsoobservethattherelativerankingamongallcarriersisconsistentwiththatinFigure1(f).
ComparedwithFigure1(b),largepacketswithsizeclosetoMTU(e.
g.
,1348bytesinAT&T)arefoundtohave2-4timesRTTofsmallpackets.
050010001500200025004812162024#ofusersTime(hour)Figure2:Numberof3GTestusersvs.
timeofday00.
20.
40.
60.
8101000200030004000TCPdownlinkthroughput(kbps)ATTVerzionSprintT-Mobile00.
20.
40.
60.
8102004006008001000TCPdownlinkRTT(ms)ATTVerzionSprintT-Mobile(a)CDFofdownlinkTCPthroughput(b)CDFofdownlinkTCProundtriptime00.
20.
40.
60.
8102004006008001000TCPuplinkthroughput(kbps)ATTVerzionSprintT-Mobile00.
20.
40.
60.
8100.
020.
040.
060.
080.
1TCPdownlinkretransmissionrateATTVerzionSprintT-Mobile(c)CDFofuplinkTCPthroughput(d)CDFofdownlinkTCPretransmissionrate00.
20.
40.
60.
81501002004008001600Ping(ms)ATTVerizonSprintT-Mobile00.
20.
40.
60.
81501002004008001600Pingtothefirsthop(ms)ATTVerizonSprintT-Mobile(e)CDFofPinglatencytolandmarkservers(f)CDFofPinglatencytothersthop00.
20.
40.
60.
81100150200250300350400DNS(ms)ATTVerizonSprintT-Mobile00.
20.
40.
60.
81501002004008001600Handshake(ms)ATTVerizonSprintT-Mobile(g)CDFofDNSlookuptime(h)TCPhandshaketimetolandmarkserversFigure1:TCPperformancecomparisonamongcarriers(datafromdeployedapplication3GTest,onlyU.
S.
)5.
2TimeofdaycorrelationUnderstandingwhethertrafcpatternsexhibitanytimeofdaybehaviorisusefulforimprovingthedesignofapplicationsandmo-bilenetworkinfrastructure.
Weexpectsmartphoneuserstohavediurnalpatternsintheirbehavior.
Forexample,wecanobservesuchapatterninFigure2.
Tofurtherunderstanditsimpactonperformance,wesearchforsuchapatterninthedatacollecteddur-ing5contiguousweekdaysasaninitialinvestigation.
Thedatasetisfrom3GTest-Localdescribedin§4.
3withresultsshowninFig-ure3.
First,timeofdayeffectislesspronouncedforuplinkthrough-putcomparedtodownlinkthroughput,comparingFigure3(a)and(d).
Thisislikelyduetohigherdemandfordownlinkcapacitybypopularapplicationssuchaswebbrowsingandvideostreaming.
Second,weobserveanobvioustimepatternforAT&T'sdown-linkthroughput.
Atnightandearlymorninghours,between2amand8am,thedownlinkthroughputcanreach1Mbps.
However,thedownlinkthroughputoflowerthan500kbpsisobservedatothertimes.
Thisphenomenonispossiblyduetothelargenum-berofiPhoneusersandthelargetrafcvolumebroughtbyvariousnetworkapplications.
ForSprintandVerizon,weobservesimi-larthoughlessprominenttrendcomparedtothatforAT&T.
ForT-Mobile,theTCPdownlinkthroughputismorestable,whichweconjectureisduetothefactthatits3Gservicehasonlyrecentlybecomeavailableatourlocation.
Figures3(b)&(c)indicatethatRTTandretransmissionrateex-hibittimeofdaypatternforsomecarriers.
ForAT&T,thedownlinkthroughputisfoundtobemostlyaffectedbyRTTvalues,likelytobecausedbyqueueingdelaysinAT&T's3Gnetworks.
RTTvariesfrom300msduringlatenightstoashighas700msatpeaktimes.
ForVerizonandSprint,theRTTvaluesaremorestable,thoughwithvaryingTCPretransmissionrate.
OnepossibleexplanationisthatinVerizonandSprint's3Gnetworks,sharedqueueswoulddroppacketsoncethequeuelengthexceedsathreshold.
Thisde-signwillrestrictthevariationofRTTbutincurmorepacketlosses.
5.
3SignalstrengtheffectsSignalstrengthisanimportantfactorthataffects3Gnet-workperformance,sincehighersignal-to-noiseratio(SNR)allowshigherbitrate.
Wethereforealsocarriedoutexperimentstoun-derstandthiscorrelation.
Sinceitisnoteasyforustocontrolthesignalstrength,wecontinuouslymonitorsignalstrengthandTCPdownlinkthroughputduringaweek.
Duetospacelimitation,weonlyhighlightourmajorobservationshere.
Whenthesignalstrengthistooweak,TCPconnectionswilldisconnect.
Whensig-nalstrengthisatsomemiddlerange,weobserveclearcorrelationbetweensignalstrengthandTCPdownlinkthroughput.
TCPdown-linkthroughputisnotaffectedbythesignalstrengthifthelatterisabovesomethreshold.
Giventheseobservations,weexcludethedatapointscorrespondingtopoorsignalstrengthfromthe3GTest-Localdataset.
5.
4Smartphonevs.
laptopTounderstandwhetherthecomputationcapabilityofasmart-phonelimitsits3Gperformance,wesetupacontrolledexperimenttocompareasmartphone(iPhone3G)withalaptop(ThinkPadT42).
ThelaptopcanaccessAT&T's3Gnetworkviaawirelessdatacard,whiletheiPhonemeasurementisconductedatthesamelocationandthesametime.
Wefoundthatthedistributionofdown-linkthroughputissimilar,implyingthattheperformancebottle-neckiswithinthe3Gnetworkinsteadofonthephone.
However,forothercomputation-intensiveapplications,theperformancedif-ferenceismorepronounced.
Wewillstudythisinmoredetailsin§6.
4.
Summary:Themainobservationsof3Gnetworkperformanceare:1.
Typicalvaluesfor3Gthroughputrangefrom500kbpsto1Mbpsfordownlink,and200kbpsto400kbpsforuplink,bothlowerthantheadvertisedrates.
2.
Networkperformancediffersacrossallcarriers.
Fordown-linkRTTandthroughput,thedifferencesamongcarriersareevident.
3.
SprintandVerizonhavehigherTCPretransmissionratecom-paredwithAT&TandT-Mobile.
4.
Largepacketscanhave2-4timesRTTofsmallpackets.
5.
Somecarriersshowcleartimeofdaypatternonweekdays,especiallyforAT&T'sdownlinkthroughput.
6.
ForsimpleTCPdownloading/uploading,theperformancebottleneckiswithinthe3Gnetwork.
7.
3Gwirelessdelaydominatestheend-to-endRTT.
OurobservationssuggestthatthelowuplinkthroughputandlargeRTTofcurrent3Gnetworksraisechallengesforofoadingcomputationintothecloud.
Networkapplicationdesignersshouldavoidchattyprotocolsandminimizetotalbytestotransfer.
3Gop-eratorsneedtoexaminetheirqueueingandlinklayerretransmis-sionpoliciestoreducelatencyinwirelesslinks.
6.
WEBBROWSINGPERFORMANCESTUDYGiventhepreviousdiscussionsontheperformanceof3Gnet-works,wenowexamineoneofthemostpopularapplicationsonsmartphone,namelywebbrowsing,inadditiontotwootherpopu-larmobileapplications,streamingvideoandVoIPin§7.
Notethatmanyfactorsjointlydetermineuserperceivedperformance,asanapplicationmaynotfullyutilizeavailablenetworkbandwidthduetolimitedprocessingpowerormemoryonthephone[24].
Ourstudyshowsthattheavailable3Gbandwidthisoftennotfullyutilizedforwebbrowsing,andseveralmodicationscanbeappliedtocurrentwebbrowsersonsmartphonestomakebetteruseofavailablenetworkresources,e.
g.
,increasingthelimitonconcur-rentTCPconnectionsperdomain,optimizingJavascriptenginesetc.
Wealsoevaluatetheeffectivenessofafewcontentoptimiza-tiontechniques,includingcompressionandtherecently-proposeddataURLscheme[15].
Inthefollowing,westudytheimpactofnetworkcondition,browserconcurrency,compression,andJavascriptexecutionspeedonwebperformance.
Wethenbreakdownthepageloadingtimeintoseveralmajorcomponentsandidentifytheperformancebot-tleneckforsomemobiledevices(§6.
6).
6.
1NetworkeffectsonwebbrowsingTounderstandhownetworkconditionaffectswebbrowsing,wexthewebcontent,servercongurations,browserconcurrencyandonlyvarythenetworkcondition.
Weemulatethe3Gnetworkcon-ditionbyinjectingpacketdelayandlossontheWiFinetworkpathasdescribedin§3.
Figure4(a)showspagedownloadingtimeincreaseslinearlywiththeRTTbetweensmartphoneandourlocalwebserver.
Thedown-loadingtimeiscomputedbyaveragingacross20replicatedURLs,witheachURLvisited3times.
Thisisexpectedasthroughputisin-verselyproportionaltoRTT.
Noadditionalpacketlossisintroducedsinceprevioussectionshowspacketlossesarerarein3Gnetworks.
ThebaseRTTinourWiFinetworkisbetween30msand50ms.
Thex-axisinFigure4(a)showstheactualRTTafterinjectingex-tradelay.
Wecanobservethatunderthesamenetworkcondition,downloadingtimevariesacrossphonesthoughtherelativerankingremainsconsistent.
Notethatwebbrowsingcannotfullyutilizetheavailablenetworkbandwidth,duetopageexecutionandrenderingonthephone.
Figure4(b)showstheeffectofvaryingdownlinkpacketlossrateforaxedRTTvalueof400ms.
Againtherankingindownloadingtimeacrossphonesisconsistent.
Forsmallpacketlossrate,e.
g.
,2%,thereislittleperformancedegradation.
However,with10%lossrate,thepagedownloadingtimeincreasesupto35seconds.
Insummary,smartphonewebbrowsingperformanceheavilydepends020040060080010001200140005101520Downlinkthroughput(kbps)Timeofday(hour)iPhone/ATTSamsung/VerizonPalm/SprintG2/T-Mobile010020030040050060070080005101520TCPdownlinkroundtriptime(ms)Timeofday(hour)iPhone/ATTSamsung/VerizonPalm/SprintG2/T-Mobile(a)TCPdownlinkthroughputvs.
timeofday(b)TCProundtriptimevs.
timeofday00.
0050.
010.
0150.
020.
0250.
030.
0350.
0405101520TCPdownlinkretransmissionrateTimeofday(hour)iPhone/ATTSamsung/VerizonPalm/SprintG2/T-Mobile05010015020025030035005101520Uplinkthroughput(kbps)Timeofday(hour)iPhone/ATTSamsung/VerizonPalm/SprintG2/T-Mobile(c)TCPretransmissionratevs.
timeofday(d)TCPuplinkthroughputvs.
timeofdayFigure3:CorrelationbetweenTCPperformanceandtimeofday(3GTest-Local)onnetworkdelayandlossconditions.
6.
2ConcurrentTCPconnections3Gnetwork'sdownlinkthroughputasmeasurednormallyrangesfrom500kbpsto1Mbpsforthecarrierswestudied(Figure1(a)).
WeusedthephonestovisitthechosenURLsandfoundthattheaveragethroughputisonlybetween20kbpsand50kbps,indicatingthatmoreconcurrentTCPconnectionscanpotentiallyimprovewebbrowsingperformance.
Currentwebbrowsersonsmartphonesalreadyallowconcurrentconnections.
Inbrowser'ssettings,thereisaparameterspecifyingthemaximumnumberofconcurrentTCPconnectionsperdomain.
OnWindowsMobilephones,itisaregistryvaluenamedMaxCon-nectionsPerServerwithadefaultvalueof4.
Whenwesetthevaluetobesmallerthan4,weobservedecreasedconcurrency.
However,whenweincreasethevaluetobelargerthan4,theconcurrencydoesnotincreaseaccordingly.
Thisimpliesthereexistsanothersettingonmaximumallowedconcurrencyperdomain,whichwecannotcongure.
ForiPhoneandGPhone,weareunabletosetthisparametereither.
Wedesigncontrolledexperimentstomeasurethedefaultconcurrencysettingondifferentplatformsandfoundittobe4forallthephonesstudied.
WealsofoundthatnoHTTPpipeliningsupportispresentontheseplatforms.
Webobjectsarefetchedsequentiallywithinaper-sistentconnection,andbrowserwillnotsendanewHTTPrequestbeforedatatransferofthepreviousrequestcompletes.
Weana-lyzedthe20popularURLsandfoundthatthereare10.
8imagesembeddedineachpageonaverage,alongwithseveralothertypesofembeddedobjects,suchasJavascript,CSSles,etc.
Thoseweb-siteswhichdonothaveamobileversion,tendtohaveevenmoreobjects.
Tounderstandhowconcurrencyaffectswebbrowsingperfor-mance,wedevisedasetofexperiments,withresultsshowninFigure4(c).
Werstvarythemaximumconcurrentconnectionsallowedattheserversidefrom1to4.
Weobserveasignicantperformancedegradationacrossallplatformswithmorerestrictedconcurrency.
Undertherestrictionofasingleconnectionperdo-main,webbrowsingis3.
5to4.
5timesslowercomparedtothatun-derthedefaultsetting.
Thisindicatesthattoday'smobilebrowsersalreadybenetmuchfromconcurrency.
Tounderstandwhetherfurtherincreasingconcurrencywillim-proveperformance,wetakeacleverapproachofDNSaliasing(§3.
2.
2)tobypasstheconcurrencylimitonthephonesinceweareunabletochangethissettingdirectly.
Figure4(c)showsthatthephonescanindeedattainahigherlevelofconcurrency.
Forexam-ple,iPhoneandG2canestablishupto9concurrentconnectionsforsomecontent-richURLs.
Theconcurrencyforotherphonesareslightlylower(6to7),likelyduetotheirslowerrenderingandexe-cutionspeed.
Generally,animprovementof30%isobservedwhenconcurrencylimitonthephoneisremoved.
ThismeansthatgiventheselectedpopularURLs,andgivencurrentnetworkcondition(withRTTof400ms),thedefaultconcurrencysettingonmobilebrowsersappearstobetooconservative.
Allowinghigherconcur-rencycanhelpphonesmakebetteruseofavailablebandwidthandsavepagedownloadingtime.
6.
3ContentcompressionCompressioncandramaticallyreducewebcontentsize.
Fortextobjects,suchasHTML,CSS,Javascript,PHP,etc.
,theobjectsizecanbereducedbyaround70%.
Usually,awebserverdoesnotcompressimageobjects.
WecalculatethecompressionratioforthepopularURLsincolumnCompressofTable3,showingthatthecontentsizecanbereducedbymorethan50%formostoftheURLswestudied.
Whilecompressionreducesthebytestransferredoverthenet-024681012140100200300400500600700800900Pagedownloadingtime(s)Roundtriptime(ms)iPhoneSamsungPalmG2HTC05101520253035400246810Pagedownloadingtime(s)Downlinkpacketlossrate(%)iPhoneSamsungPalmG2HTC(a)Effectofroundtriptimeonwebbrowsing(b)Effectofdownlinkpacketlossrateonwebbrowsing010203040501234OPTPagedownloadingtime(s)MaximumparallelismobservediPhoneSamsungHTCG2051015200100200300400500600700800900Pagedownloadingtime(s)Roundtriptime(ms)iPhone:compressiPhone:nocompressG2:compressG2:nocompressSamsung:compressSamsung:nocompress(c)Effectofparallelismonwebbrowsing(d)EffectofcompressiononwebbrowsingFigure4:FactorsimpactingwebbrowsingperformanceURLText1ImageSize(KB)Original(KB)2Compress3GZIPLines/index4RedirectServerIPswww.
google.
com4179.
277.
62.
5614-2m.
bing.
com4342.
9218.
11.
46-2-1maps.
google.
com610479.
8656.
02.
788-4mapquest.
com613135.
11326.
351.
9675226xhtml.
weather.
com22941.
4977.
32.
53-7042m.
youtube.
com5377.
6490.
12.
34231-3m.
ebay.
com4358.
6484.
02.
17-1-1m.
facebook.
com4119.
7399.
12.
81722m.
myspace.
com3214.
6600.
22.
69812m.
fox.
com426306.
62083.
01.
16297-4mobile.
craigslist.
org30113.
8113.
83.
58652-11ThiscolumnshowsthenumberoftextobjectsincludingHTML,JavaScriptandCSSles2ThiscolumnshowsthetotalsizeoftheoriginalwebsiteforeachmobileURL,forexample,www.
bing.
comfortherowofm.
bing.
com3ThiscolumnshowsthecompressionratioformobileURLs,totalsizeinnocompressionmode/totalsizeincompressionmode4ThiscolumnshowsthetotalnumberoflinesintheindexpageindicatingwhetherminicationisusedTable3:Characteristicsoftoday'spopularmobilewebsiteswork,decomressionwillincreasecomputationoverheadonthephone.
Tounderstandthistradeoff,wevaryRTTcoveringthemea-suredrangeandcomparethewebbrowsingperformanceincom-pressedanduncompressedmodes.
InFigure4(d),weexcludetheresultsforHTCandPalmphonesastheyshowsimilartrends.
Weobservethatcompressionconsistentlyhelpstoimprovewebper-formance,irrespectiveoftheRTTvalues.
Itisespeciallyhelpfulunderpoornetworkcondition.
Forexample,itreducesiPhone'spagedownloadingtimeby30%whenRTTis800ms.
6.
4JavascriptexecutionGiventhelimitedprocessingpoweronsmartphones,HTMLren-deringandJavascriptexecutionmaybecomethebottleneckforwebbrowsing.
Severalfactorsjointlydeterminethepageprocessingspeed,includingCPUfrequency,memory,OS,andbrowser.
EvenforthesameOS,suchasWindowsMobile6.
1,phonevendorscanhavedifferentbuildsfordifferentmodelsofphones.
WemeasuredJavascriptexecutiontimeondifferentphonesus-ingabenchmarkconsistingof26differentJavascripts[8].
Fig-ure5(a)showsthetotaltimetakentoexecutethebenchmarkondifferentphones.
Theresultsdemonstratethatexecutiontimeis20-80timeslongeronsmartphonesthanondesktopcomputers.
Amongthesmartphones,G2hasthebestperformancefollowedbyiPhone.
Forexample,G2is3timesfasterthantheHTCphone.
SuchperformancegaphelpstoexplainthedifferencesinthepageloadingtimeofG2andiPhonecomparedtothatoftheSamsungHTC/ATT3GHTC/WiFiPalm/Sprint3GPalm/WiFiSamsung/Verizon3GSamsung/WiFiiPhone/ATT3GiPhone/WiFiG2/TMobile3GG2/WiFi05101520253035Webbrowsingbreakdown(sec)TCPIdleTCPtransferTCPhandshakeDNSlookupHTC/ATT3GHTC/WiFiPalm/Sprint3GPalm/WiFiSamsung/Verizon3GSamsung/WiFiiPhone/ATT3GiPhone/WiFiG2/TMobile3GG2/WiFi05101520253035Webbrowsingbreakdown(sec)TCPIdleTCPtransferTCPhandshakeDNSlookup(a)Webbrowsingbreakdownform.
ebay.
com(URLa)(b)Webbrowsingbreakdownformapquest.
com(URLb)Figure7:WebbrowsinganatomyfortwopopularmobilewebsitesHTC/IEPalm/IESamsung/IEiPhone/SafariG2/BrowserPC/Firefox050100150200250300350TimetofinishtheJavaScriptbenchmarks(sec)Figure5:ScriptexecutionspeedfordifferentplatformsiPhone/SafariG2/Browser00.
511.
522.
533.
54Pageloadingtime(sec)Loadingtimeoforiginalpage(s)LoadingtimewithdataURLscheme(s)Figure6:EvaluationfordataURLschemeandPalmphonesunderthesamenetworkconditionsinFigure4.
LargeJavascriptexecutiontimeleadstomoreTCPidletimeandunder-utilizationofnetworkbandwidth.
Thisexperimentshowsthatnetworkisnottheonlybottleneckforwebbrowsingperformance.
Phoneitselfalsoplaysamajorrole,underscoringthenecessityofmeasuringapplicationperformanceonrealsmartphones.
WebdesignersshouldavoidusingcomplexJavascriptswhenbuildingmobileversionsoftheirwebsites.
6.
5Serverconguration&contentoptimiza-tionServercongurationsandcontentoptimizationareimportantfactorsforwebbrowsingperformance.
Onetypeofservercon-gurationisthemaximumconcurrentconnectionswithaclient.
In§6.
2,wefoundthatmobilebrowserssetadefaultconcurrencylimitof4perdomain.
However,wedidnotobserveanywebserverslimittheconcurrencyperclienttobesmallerthan4,likelybecauseservershavetheincentivestoattaingoodwebbrowsingexperi-ence.
Thecompressioncongurationissimilarlyimportant,withtheidentiedsettingoftheURLsstudiedshownintheGZIPcol-umninTable3.
Despitethefactthatcompressionalmostalwayshelpswithwebbrowsingperformance(§6.
3),wefoundsomeweb-sitesdonotenableitbydefault.
Variouscontentoptimizationtechniquesalsohelptoimprovewebbrowsingperformanceonsmartphones.
Mostpopularweb-sitesalreadycustomizetheircontentsformobileusers,withmoreconcisetextsandfewerandsmallerimages,e.
g.
,viacodeminica-tion[2],imagescaling,etc.
Westudyinparticularcodeminica-tionwhichreferstotheeliminationofredundantcharacters,suchasspaces,tabs,linebreaks,etc.
Thesizereductionvariesfrom5%to25%fortheURLsstudied.
ColumnLines/indexinTable3showsthenumberoflinesintheindexpageofawebsite,providingahintforwhetherminicationisused.
Thenumberoflineswillbesmallforindexpagestreatedwithminication.
ItseemsthathalfoftheURLsusethistechniquetooptimizetheircontents.
AnothertypeofoptimizationhelpstoreducethenumberofHTTPrequestsusedtofetchcontents,includingthedataURLscheme[15],CSS3,etc.
ThegeneralideaistoeliminateTCPcon-nectionsandHTTPrequestsforsmallobjects,suchasthecornerimageofapage.
WesetupacontrolledexperimenttodemonstratetheeffectivenessofthedataURLscheme,underwhichsmallim-agesareintegratedwiththemainHTMLpageratherthanlinkedasseparateobjects(4.
4).
Inourexperiment,wefoundthattheimagesareactually1.
3-1.
5timesofitsoriginalsizeunderthedataURLscheme.
Figure6showsthatitcutspageloadingtimebyabout20%.
ThedataURLschemehasnotbeenubiquitouslysupported.
Infact,onlythebrowserofiPhoneandG2supportsit.
WealsodidnotobserveanyURLswestudiedadoptthistechnique,possiblyduetotheconcernoflackofbrowsersupport.
Withoutbrowsersupport,theimagerepresentedbythedataURLschemewillbedisplayedasadefaulterrorimage.
Redirection(HTTPresponsecode301and302)isanotheris-suewhichmayadverselyimpactwebbrowsingperformance.
Formobilewebbrowsing,thisissuebecomesmorepronouncedgiventhelargeRTTsin3Gnetworks.
IncolumnRedirectofTable3,wefoundthatsomewebsiteshavemultiplelevelsredirections.
Forexample,m.
weather.
comwillberedirectedtoxhtml.
weather.
comandthentomw.
weather.
com.
Insomecases,usersareredirectedtoanotherURLwhichisquitesimilartotheoriginalone.
Inothercases,webobjectshavebeenmovedtoanewlocation,andtheoriginalURLsimplyredirectstheincomingre-PalmSamsungiPhoneG2050100150200Totalcontentsizeof37:40YouTubevideo(MB)3GWiFi02004006008001000120005001000150020002500Averagethroughput(Kbps)Time(sec)iPhone02004006008001000120005001000150020002500Averagethroughput(Kbps)Time(sec)G2(a)Videocontentsize(b)iPhonetimelinefor2260-secvideo(c)G2timelinefor2260-secvideoFigure8:Streamingvideoperformance:contentsize,downloadstrategy.
queststothenewlocation.
Wethinksomeoftheseredirectionsareunnecessaryandcanbeeliminatedwithbetterwebpagedesign.
6.
6Webbrowsingvia3GnetworksFigure7showsthecasestudyfortwogroupsofURLslistedinTable3.
GroupAcorrespondstotheURLsthathavecon-ciseandsimplecontents,e.
g.
,m.
ebay.
com(URLa)contains7objectswithatotalsizeof58.
6KB.
Manyofthesewebsitesaresearchenginesorportalstosocialnetworkingsites,includ-ingwww.
google.
com,m.
bing.
com,m.
myspace.
com,andm.
facebook.
com.
GroupBconsistsofwebsiteswithrichcon-tents,e.
g.
,mapquest.
com(URLb)has19objectswithato-talsizeof135.
1KB.
Otherwebsitesinthegroupincludeonlinemap(maps.
google.
com),informationexchange(mobile.
craigslist.
org),andnews(m.
fox.
comandm.
cnn.
com).
TherearetwosetsofdatainFigure7.
OnesetiscollectedwheneachsmartphonevisitstherealURLsvia3Gnetworks.
Toelim-inatethedifferencesindownloadedcontentsandnetworkcondi-tions,eachphonealsovisitsthereplicatedURLsviaWiFiwithaRTTof400mstoemulatethetypical3Gnetworkconditions.
ItisclearthatallsmartphonesexperiencesmallerpageloadingtimeforthesimpleURLinFigure7(a)comparedwiththatforthecontent-richURLinFigure7(b).
Webreakdownthepageload-ingtimeintofourparts:TCPtransfer,TCPidle,DNSlookup,andTCPhandshake.
Thesizeofmapquest.
comislargerthanthatofm.
ebay.
com,resultinginlongerTCPtransfertime.
Moreover,mapquest.
comcontainsmorecontentstorenderandmorecom-plexJavascriptstoexecute,leadingtolongerTCPidletime.
TheDNSlookuptimeandTCPhandshaketimecontributetolessthan10%ofpageloadingtime,whicharenegligible.
WefurtherobservethatthePalm(Sprint),Samsung(Verizon),andHTC(AT&T)phonesexperiencemuchlongerpageloadingtimeformapquest.
comcomparetoiPhone(AT&T)andG2(T-Mobile).
ThisislikelyduetotheirslowerJavascriptexecutionspeed,asshowninFigure5.
IntheWiFiexperiments,allthephonesdownloadthesamecon-tentsandexperiencethesamenetworkconditions.
Asaresult,theTCPtransfertimedifferencesamongallphonesaresmall.
How-ever,wecanstillobservesignicantpageloadingtimedifferences,mostlyduetothegapinTCPidletimes.
WefurthernotethattheirrelativerankingisconsistentwiththerankingofJavascriptexecu-tionspeedinFigure5.
Summary:First,wefoundthathigherbrowserconcurrencyenablesthephonestobetterutilizeavailablenetworkbandwidth,hencereducingpageloadingtime.
Second,servercongurationsandcontentoptimizationplayamajorroleinwebbrowsingper-formance.
Compressiontendstoalwayshelpundertypical3Gnet-workconditions.
However,afewpopularwebsitesareemploy-ingsub-optimalservercongurationsandpagedesigns.
Third,wefoundthebottleneckforwebbrowsingperformanceoftenliesinthephoneitselfratherthaninthe3Gnetwork.
7.
OTHERMOBILEAPPLICATIONSInthissection,westudytwootherpopularmobileapplications,streamingvideoandVoIP.
7.
1StreamingvideoWedownloadeda37-minutelongvideousingaYouTubeplayeroneachphone.
Figure8(a)showsthesizeofthevideodownloadedusingTCPviaWiFiand3Goneachphone.
Asexpected,thevideosizeissmallerfor3GthanforWiFi,becauseboththevideoserverand3Gcarriercancustomizevideobasedonnetworkconditionstoensuregooduserexperience.
Interestingly,thevideosizefor3Galsovariesacrosscarriers:itisthesmallestforT-Mobile,followedbyAT&T,Verizon,andSprint.
Figures8(b)(c)showtherepresentativetimeseriesofvideodownloadthroughputforiPhoneandG2via3Gnetworks.
ThetimelineofiPhoneexhibitsadistinctpatternwithclearpauses.
Itinitiallydownloadsaportionofthevideoatahighrate,thenstopsbeforedownloadingtheremainingportions.
Weconjecturethatthedownloadstopswhenthebufferedcontentexceedscertainthreshold,andresumesafterthebufferedcontentfallsbelowan-otherthreshold.
Thepurposeislikelytoaccommodatethelimitedphonememoryandtosaveenergyusageassociatedwiththe3Ginterface.
AnotherobservationisthatiPhonealwaysterminatestheTCPconnectionevery10-20secondsandthenestablishesanewoneondemand.
WeconjecturethatiPhoneattemptstoputthethe3Ginterfaceintolowpowerstatetosaveenergy.
Incontrast,G2showsadifferentbehaviorbyperiodicallydown-loadingsmallchunksofthevideoevery10seconds.
TheSamsungandPalmphonesbehavesimilarlywithaslightlylongerintervalof20secondsbetweendownloads.
Thisislikelymotivatedbythefactthatuserssometimesdonotwatchtheentirevideoandmayskimthroughcertainpartsofthevideo.
Suchdownloadingpat-ternscanalsohelptosaveenergy.
Ourinitialstudyshowsthatthevideoplayersondifferentphonesemploydifferentpoliciestofetchvideo.
Thismeritsmoredetailedfuturestudy.
7.
2VoIPWecarryoutasimpleVoIPexperimentontheSamsung(Ver-izon)andPalm(Sprint)phonesgiventheiruniformsupportforSkype.
Duringtheexperiment,thesamemusicleisplayedonboththephoneandthedesktop,whenthetwoareinaSkypecall.
Thevolumeiskeptthesametohavesimilarvoiceinput.
Figure9showsthatthethroughputforbothphonesvia3Gisnearlyidenti-cal,asthesamecodingrateisused.
ThethroughputishigherunderWiFithanunder3G,asdifferentamountofdataistransferredde-pendingonthenetworkbeingused.
ThisreectshowSkypetriestovarytheencodingrateaccordingtothenetworkconditiontoachievegoodperceivedvoicequality.
010203040506070020406080100120140160180Throughput(kbps)Time(sec)Samsung-VerizonSamsung-WiFiPalm-SprintPalm-WiFiDownlinkthroughputtimelineforSkypeFigure9:VoIPperformance8.
CONCLUSIONInthispaper,wecharacterizedtheperformanceofnetworkap-plicationsonsmartphonesinawaythatisrelevanttoendusers,cellularoperators,smartphonevendors,applicationdevelopers,aswellascontentproviders.
Wecomprehensivelystudied3Gnetworkperformancebyleveragingourwidely-deployedmeasurementtool,3GTest.
Wecarefullydevisedasetofexperimentstoquantifyhowapplicationperformance,inparticularwebbrowsing,isimpactedbyvariousfactors,andwheretheperformancebottleneckis.
Ouranalysisprovidesinsightintohownetworkoperatorsandsmart-phonevendorscanimprove3Gnetworksandmobiledevices,andhowcontentproviderscanoptimizemobilewebsites.
Ourworkrepresentsanimportantsteptowardsabetterunder-standingoftheperformanceof3Gnetworksandsmartphoneap-plications.
Asfuturework,wewillcontinuetocollectdatafrom3GTestandstudythenetworkandapplicationperformancediffer-encesacrossvariouslocations.
Wealsoplantostudyhowwebpagestructureandwebobjectdependencyaffectpageloadingtime.
9.
ACKNOWLEDGEMENTSWethankallthereviewersandespeciallyourshepherdBillSchilitfortheirconstructivecommentsandsuggestions.
ThisworkispartiallyfundedbyNSFCNS-0643612,DARPAComputerSci-enceStudyPanel,andARMYYoungInvestigatorAward.
10.
REFERENCES[1]AlexaTop500GlobalSites.
http://www.
alexa.
com/topsites.
[2]BestPracticesforSpeedingUpYourWebSite.
http://developer.
yahoo.
com/performance/rules.
html#minify.
[3]CanalysPressRelease:R2009112.
http://www.
canalys.
com/pr/2009/r2009112.
htm.
[4]FCCConsumerBroadbandTest.
http://broadband.
gov/qualitytest/.
[5]ICSINetalyzr.
http://netalyzr.
icsi.
berkeley.
edu/.
[6]Smartphone3GTest(3GTest).
http://www.
eecs.
umich.
edu/3gtest.
[7]Speedtest.
net.
http://www.
speedtest.
net/.
[8]SunSpiderJavaScriptBenchmark.
http://www2.
webkit.
org/perf/sunspider-0.
9/sunspider.
html.
[9]M.
Balakrishnan,I.
Mohomed,andV.
Ramasubramanian.
Where'sThatPhone:GeolocatingIPAddresseson3GNetworks.
InProceedingsofIMC,2009.
[10]R.
Chakravorty,S.
Banerjee,P.
Rodriguez,J.
Chestereld,andI.
Pratt.
PerformanceOptimizationsforWirelessWide-AreaNetworks:ComparativeStudyandExperimentalEvaluation.
InProceedingsofACMMOBICOM,2004.
[11]M.
C.
ChanandR.
Ramjee.
TCP/IPPerformanceover3GWirelessLinkswithRateandDelayVariation.
InProc.
ofMOBICOM,2002.
[12]J.
Chestereld,R.
Chakravorty,J.
Crowcroft,P.
Rodriguez,andS.
Banerjee.
ExperienceswithMultimediaStreamingover2.
5Gand3GNetworks.
JournalACM/MONET,2004.
[13]M.
Ghaderi,A.
Sridharan,H.
Zang,D.
Towsley,andR.
Cruz.
ModelingTCPinaMulti-RateMulti-UserCDMASystem.
InIFIP-Networking2007,2007.
[14]K.
Jang,M.
Han,S.
Cho,H.
-K.
Ryu,J.
Lee,Y.
Lee,andS.
B.
Moon.
3Gand3.
5GWirelessNetworkPerformanceMeasuredfromMovingCarsandHigh-speedTrains.
InProc.
ofACMMICNET,2009.
[15]L.
Masinter.
The"data"URLScheme.
RFC2397,1998.
[16]X.
Liu,A.
Sridharan,S.
Machiraju,M.
Seshadri,andH.
Zang.
Experiencesina3GNetwork:InterplaybetweentheWirelessChannelandApplications.
InProceedingsofACMMOBICOM,2008.
[17]R.
Mahajan,M.
Zhang,L.
Poole,andV.
Pai.
UncoveringPerformanceDifferencesinBackboneISPswithNetdiff.
InProceedingofNSDI,2008.
[18]K.
Mattar,A.
Sridharan,H.
Zang,I.
Matta,andA.
Bestavros.
TCPOverCDMA2000Networks:ACross-LayerMeasurementStudy.
InPAM,2007.
[19]J.
Padhye,V.
Firoiu,D.
Towsley,andJ.
Kurose.
ModelingTCPThroughput:ASimpleModelanditsEmpiricalValidation.
InProc.
ACMSIGCOMM,1998.
[20]W.
L.
Tan,F.
Lam,andW.
-C.
Lau.
Anempiricalstudyon3gnetworkcapacityandperformance.
InProc.
IEEEINFOCOM,2007.
[21]I.
Trestian,S.
Ranjan,A.
Kuzmanovic,andA.
Nucci.
MeasuringSerendipity:ConnectingPeople,LocationsandInterestsinaMobile3GNetwork.
InProceedingsofIMC,2009.
[22]W.
Wei,C.
Zhang,H.
Zang,J.
Kurose,andD.
Towsley.
InferenceandEvaluationofSplit-ConnectionApproachesinCellularDataNetworks.
InPAM,2006.
[23]D.
Willkomm,S.
Machiraju,J.
Bolot,andA.
Wolisz.
PrimaryUsersinCellularNetworks:ALarge-scaleMeasurementStudy.
InDySpAN,2008.
[24]Z.
Zhuang,T.
-Y.
Chang,R.
Sivakumar,andA.
Velayutham.
A3:Application-AwareAccelerationforWirelessDataNetworks.
InProc.
ofACMMOBICOM,2006.