Wireless Wakeups Revisited: Energy Management for VoIP over Wi-Fi Smartphones

Transcription

1 Wireless Wkeups Revisited: Energy Mngement for VoIP over Wi-Fi Smrtphones Yuvrj Agrwl, Rnveer Chndr,AlecWolmn, Prmvir Bhl, Kevin Chin, Rjesh Gupt Microsoft Reserch, Microsoft Corportion, University of Cliforni Sn Diego ABSTRACT IP bsed telephony is rpidly gining cceptnce over trditionl mens of voice communiction. Wireless LANs re lso becoming ubiquitous due to their inherent ese of deployment nd decresing costs. In enterprise Wi-Fi environments, VoIP is compelling ppliction for devices such s smrtphones with multiple wireless interfces. However, the high energy consumption of Wi-Fi interfces, especilly when device is idle, presents significnt brrier to the widespred doption of VoIP over Wi-Fi. To ddress this issue, we present Cell2Notify, prcticl nd deployble energy mngement rchitecture tht leverges the cellulr rdio on smrtphone to implement wkeup for the high-energy consumption Wi-Fi rdio. We present detiled mesurements of energy consumption on smrtphone devices, nd we show tht Cell2Notify cn extend the bttery lifetime of VoIP over Wi-Fi enbled smrtphones by fctor of 1.7 to 6.4. Ctegories nd Subject Descriptors C.2.1 [Computer-Communiction Networks]: Network Architecture nd Design Wireless communiction Generl Terms Algorithms, Mngement, Performnce Keywords VoIP, cellulr networks, Wi-Fi, smrtphones, power mngement 1. INTRODUCTION Voice-over-IP (VoIP) services re rpidly gining cceptnce over trditionl circuit-switched voice communiction networks such s the public switched telephone network (PSTN). Although there re mny resons behind this trnsformtion, the two most compelling resons re lower costs, nd new functionlity tht is difficult to chieve with trditionl voice networks. In homes, providers such s Vonge nd SunRocket provide very low cost long-distnce nd interntionl clling services. Skype provides free clling to other Skype users nd only chrges for clls to users outside the Skype Permission to mke digitl or hrd copies of ll or prt of this work for personl or clssroom use is grnted without fee provided tht copies re not mde or distributed for profit or commercil dvntge nd tht copies ber this notice nd the full cittion on the first pge. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission nd/or fee. MobiSys 07, June 11-14, 2007, Sn Jun, Puerto Rico, USA. Copyright 2007 ACM /07/ $5.00. network. In enterprises, VoIP lso offers new functionlity, especilly when integrted with Wi-Fi networks: VoIP over Wi-Fi llows incoming phone clls to be utomticlly routed to user s VoIP phone, regrdless of where tht user connects to the network. Other functionlity benefits include integrtion with network services such s ddress books, file exchnge in prllel with voice converstions, presence notifiction, video converstions, nd cll logging. Simultneously, new clss of mobile devices clled Smrtphones re gining populrity. Smrtphones integrte the functionlity of PDAs nd mobile phones into one device. They typiclly run full-fetured operting system, such s Windows CE or Linux, nd most recent smrtphones re equipped with multiple wireless network interfces, such s Wi-Fi nd cellulr interfces (GSM or CDMA). As smrtphones become ubiquitous, users will demnd the bility to use single device for ll their telephony needs. They will use their smrtphone s cellulr phone primrily when on the rod, nd they will use it primrily s VoIP phone when t work or t home. Therefore, VoIP over Wi-Fi hs emerged s criticl ppliction for smrtphones. Vendors such s T-Mobile hve recognized this trend nd re in the process of rolling out new functionlity tht enbles the hndoff of clls between their GSM networks nd their Wi-Fi networks [29]. One criticl issue tht presents brrier to the widespred doption of VoIP on smrtphones is tht of high energy consumption. In order for smrtphones to receive VoIP clls over the Wi-Fi network interfce, tht interfce needs to be on continuously. Unfortuntely, the energy consumption of Wi-Fi interfces when there is no dt trnsfer tking plce is comprble to tht of when the interfce is ctive [20, 23]. Furthermore, s we demonstrte in Section 3, the energy consumption of the idle Wi-Fi network interfce, even with power sve mode enbled, vstly exceeds the energy consumption of the smrtphone s GSM rdio in its idle stte. The better energy consumption of the GSM interfce is chieved by rpid duty cycling of the GSM rdio with predictble timing due to the TDMA MAC protocol, in ddition to tight integrtion with cellulr bse sttions. In contrst, Wi-Fi uses distributed MAC (CSMA/CA) where devices lwys contend for ccess to the wireless medium thus leding to incresed energy consumption due to excessive listening for trffic from other nodes. In this pper, we present Cell2Notify, n energy mngement rchitecture tht leverges the presence of multiple rdios on the smrtphone to reduce the idle energy consumption of the Wi-Fi rdio. Cell2Notify ttempts to minimize energy consumption by powering off the Wi-Fi interfce when there is no VoIP cll in progress, nd powering it on only on the reception of n incoming VoIP cll. To provide the wkeup mechnism for the Wi-Fi interfce, we utilize the voice services of the GSM rdio. An incom- 179

2 ing ring over the GSM chnnel, combined with unique cller-id of tht incoming cll, serves s unique identifier such tht the smrtphone cn distinguish between wkeup ring nd regulr incoming phone cll over the GSM interfce. Upon reception of wkeup ring, the smrtphone powers on the Wi-Fi interfce nd then receives the ctul incoming VoIP cll. Previous reserch efforts [20,23] on energy mngement for multirdio devices hve lso investigted the ide of wireless wkeups: switching between rdios on multi-rdio devices to reduce the overll energy consumption. Since different rdios usully hve different performnce nd energy chrcteristics, these systems select the best rdio for the current worklod nd keep other rdios powered off. Cell2Notify is continution long this line of reserch, with two importnt distinctions. Previous pproches hve fced significnt brriers to deployment due to the substntil infrstructure modifictions needed, wheres Cell2Notify simply requires softwre chnges on the smrtphone devices nd on the VoIP proxy. There re no chnges needed to the VoIP protocol (in our cse SIP [21]), nd no dditionl hrdwre infrstructure to deploy. Moreover, Cell2Notify is trgeted t specific compelling ppliction of VoIP over Wi-Fi. We present the design nd implementtion of Cell2Notify. We hve implemented Cell2Notify on Asterisk, commonly vilble open-source SIP proxy, nd on Windows XP clients. Our mesurements show tht the dditionl ltency imposed by our wkeup mechnism is less thn two rings. Bsed on cll logs from cell phones nd office phones, we estimte tht Cell2Notify cn extend bttery lifetime of typicl smrtphone device by fctor of 1.7 to 6.4. We show the ese of Cell2Notify deployment by demonstrting working prototype using the Cingulr cellulr network nd Microsoft s corporte Wi-Fi network we did not require ny infrstructure chnges to these networks, nor ny coopertion from network dministrtors. 2. OVERVIEW OF A VOIP DEPLOYMENT VoIP enbles voice communiction over IP-bsed networks, such s enterprise LANs or WANs s well s the Internet. VoIP protocols digitize voice into pckets, nd then send them using stndrd IP routing. Since VoIP does not require dedicted nd complex switching infrstructure s the PSTN does, it is much cheper. It cn lso provide enhnced dt services, such s video conferencing nd fx t much lower cost. In the rest of this pper, we minly consider VoIP in enterprise LANs, lthough our protocols cn be esily extended to work over the Internet. We illustrte typicl enterprise VoIP deployment in Figure 1. The primry components of ny VoIP deployment re VoIP proxy server, VoIP enbled soft phones, nd VoIP gtewy. The soft phones re PCs, PDAs or smrtphones tht re running softwre codecs nd digitize voice pckets. The VoIP proxy server cts s rendezvous point for VoIP connections. It uses stndrdized signling protocols, such s SIP [21] or H.323 [22], to estblish VoIP cll between the clling prties. Once the cll is connected, it is completed in peer-to-peer fshion between the clling prties, without routing vi the VoIP proxy. A typicl VoIP deployment lso integrtes with the PSTN using VoIP gtewy. The gtewy usully hs n Anlog Telephony Adpter (ATA) tht bridges the clls between the IP-bsed LAN nd the PSTN. In scenrios where one clling prty is on the PSTN, the VoIP gtewy server lso plys the role of VoIP endpoint. The VoIP proxy nd the VoIP gtewy services re often implemented by the sme mchine. One of the most populr stndrds used in VoIP deployments is the Session Initition Protocol (SIP). SIP [21] is trnsport independent ppliction-lyer protocol tht provides frmework for IP Phone Internet PSTN Soft Phone Wi-Fi interfce GSM/CDMA interfce ATA Access Point LAN SIP Server Cellulr Network Enterprise Network Smrt Phone Bse Sttion Figure 1: A typicl enterprise VoIP deployment. Outside cllers cn either mke VoIP clls over the Internet or over the PSTN line. The SIP server uses n Anlog Telephony Adpter (ATA) to trnslte the cll from PSTN to IP nd vice-vers. inviting end-hosts into converstion. Similr to HTTP, SIP is text-bsed protocol which mkes it extremely simple, efficient nd extensible. Soft phones use SIP to register with the VoIP proxy server. When the proxy receives cll for the soft phone, it sends SIP invite messge to the soft phone. In response, the soft phone my send ringing messge bck to the server. When the user picks up the phone, it sends SIP 200 OK messge tht indictes tht cll setup is complete. The widespred deployment of enterprise Wi-Fi networks dds n interesting dimension to VoIP in terms of support for mobility. An employee with Wi-Fi VoIP phone cn receive clls when working in conference room or collegue s office without relying on explicit cll forwrding. 3. WIRELESS INTERFACE CHARACTERISTICS In this section, we look t energy consumption nd dt trnsfer chrcteristics of different wireless interfces. We investigte how these chrcteristics impct the selection of the best wireless interfce to use for VoIP. In prticulr, we study the chrcteristics of two cellulr dt networks (GPRS/EDGE nd 1xEVDO), s well s the Wi-Fi interfce. We then profile the energy consumption of the entire smrtphone device while performing vrious tsks to motivte the need for our Cell2Notify system. 3.1 Cellulr Dt vs. Wi-Fi Since cellulr rdios re typiclly highly optimized to sve energy, one possibility for mking VoIP clls cn be to use smrtphone s cellulr dt connection. We performed set of mesurements to investigte this lterntive, nd found tht the cellulr rdio consumes significntly more power when used for dt trnsmissions, even more so thn the Wi-Fi interfce. In this section, we present experimentl results to show the energy consumption of two populr cellulr dt connections: GPRS/EDGE nd 1xEVDO, nd compre these numbers with the energy consumed over Wi- Fi. To the best of our knowledge, ours is the first pper tht compres energy consumption of these wireless interfces when used for VoIP communiction. We mesured the energy consumption when ccessing two dif- 180

3 ferent cellulr dt network technologies prevlent in the US, nmely GSM nd CDMA. The GPRS/EDGE dt service is bsed on the GSM technology, nd is offered by providers such s Cingulr nd T-Mobile. The 1xEVDO dt service is bsed on CDMA nd is offered by Verizon nd Sprint. Since it is difficult to obtin ccurte power mesurements from smrtphone s we demonstrte in the next section, we used PC crds from Verizon nd Cingulr inserted in lptop to obtin power mesurements. For Cingulr, we used the Sony Ericsson GC83 crd to ccess their GPRS/EDGE network, nd for Verizon we used the Verizon V620 crd to ccess the 1xEVDO network. For both networks, we obtined good signl strength in the lb where we performed the experiments. For our Wi-Fi mesurements, we used the commonly vilble Netger WAG /b/g crdbus dpter. To mesure the power consumption of our PC crds, we plugged them into our lptop using PC crd extender device. The extender exposes vrious pins tht help us in mesuring the power used by the the PC crd. Our setup is similr to the system used in [20,23]. We ttched 20 m-ohm sense resistnce in series with the wireless crd, nd mesured the current through the resistor using dt cquisition system. The current multiplied by the supply voltge yields the power consumed by the PC crd. We performed power mesurements for three different sttes of ech wireless crd. The first is the not connected stte, in which the crds were not connected to the dt network. This corresponds to the not ssocited stte for Wi-Fi crd. The second is the connected nd idle stte, in which the crds re connected to the dt network but not sending ny trffic. The third stte is the connected nd ctive stte, where the crd is connected to the network nd is sending nd receiving VoIP trffic over UDP. In our experiments, we used the populr g729 VoIP codec, which genertes 50 byte VoIP pckets t dt rte of 31.2 Kbps. We report the power mesurements for vrious sttes of the crds in Figure 2. As shown in the Figure, the power consumption of the V620 (1xEVDO) crd is quite substntil in both the not connected nd the connected nd idle sttes. The SE-GC83 (GPRS/EDGE) interfce consumes much less power in those sttes. The V620 utility ctively tries to serch for the dt network, nd shows the signl strength of the network even in the not connected stte. Furthermore, it sends periodic keep-live messges in the connected nd idle stte, nd consumes significnt power. On the other hnd, the SE-GC83 utility does not connect unless sked to do so, nd stys in low power stte when connected nd idle. Another interesting fct tht is unique to the 1xEVDO rdio is tht the energy consumption is not s much dependent on the number of pckets sent on the network s it is on the fct tht the interfce is switched on. This cn be seen from the similr power consumed in the not connected nd the connected nd idle sttes for the 1xEVDO interfce. Further, the 1xEVDO interfce incurs significnt overhed in power, ltency nd network resources when the rdio is woken up from sleep mode. Consequently, the 1xEVDO interfce uses conservtive policy to decide when to enter deep sleep mode. Note tht the Wi-Fi crd consumes the most energy when it is not connected, s it keeps scnning for vilble wireless networks. The energy consumption reduces significntly when the crd is connected (ssocited) s it enters IEEE Power Sve Mode (PSM) [12]. Of ll three interfces, the Wi-Fi interfce is the most power efficient rdio during n ctive VoIP cll. It consumes less thn hlf the energy of the V620, nd less thn 75% of the energy consumed by the GPRS/EDGE rdio. This cn be explined by the high trnsmit power used by the cellulr rdios to send dt over much longer distnces (sometimes even miles) compred to Wi-Fi, where the ) ts (W r e w o P Verizon V620 (EVDO) SE-GC83 (GPRS/EDGE) Netger WAG511 Not Connected Connected nd Idle Connected nd Active Figure 2: Power mesurements of 1xEVDO, GPRS/EDGE nd Wi- Fi interfces for different scenrios. The Connected nd Active mesurements show the power when trnsmitting 32 Kbps of VoIP trffic over UDP. Note tht when ctive, VoIP over Wi-Fi consumes the lest mount of bttery power. Interfces Jitter (ms) Pcket Loss (%) Verizon V Cingulr SE-GC Netger WAG Tble 1: VoIP Qulity over different network interfces. AP is usully within 100 meter distnce. This is excerbted by the strict rel time requirements for VoIP nd short inter pcket genertion time, s result of which the cellulr rdios hve no opportunities to sleep nd conserve energy. Most of the power numbers we present in Figure 2 re consistent with recent pper by Mhmud et. l. [18], which compres the power consumption of Wi-Fi nd GPRS interfces. However, in our mesurements, we found tht the Wi-Fi interfce in the Connected nd Idle stte consumes significntly more power thn wht ws reported in [18]. We believe our mesurements re ccurte s it is consistent with numbers presented in number of relted ppers [2, 23]. Although it might be possible to further reduce the power consumption of the Wi-Fi interfce, we note tht our Cell2Notify scheme would still be beneficil s it completely disbles the Wi-Fi interfce when it is not in use in n ctive VoIP cll. In ddition to high power consumption, the performnce of cellulr dt interfces is lso not well suited for rel-time pplictions, such s VoIP. We mesured two metrics, jitter nd loss rte, which re usully ssocited with the qulity of VoIP connection, nd we present those results in Tble 1. All three interfces hd resonbly good connection to their respective networks. The results show tht the qulity of VoIP clls is much better over the Wi-Fi connection thn over the cellulr dt networks. In fct, the high ltency over the cellulr dt interfce mkes voice trffic intolerble. There re severl other resons why the cellulr dt network is not idel for VoIP trffic in n enterprise. The costs re greter, becuse ll employees (or the enterprise) needs to purchse cellulr dt pln, nd these tend to be expensive. In most cses, this needs to be n unlimited dt connection since VoIP clling genertes significnt mount of trffic. The enterprise lso hs no control over clls using this pproch, since the first hop from the smrtphone is the cellphone crrier. Consequently, it is extremely 181

4 Scenrio All Rdios off (Flight Mode) GSM Idle Wi-Fi (serching) Wi-Fi (connected) Wi-Fi (send/recv) Power mw mw mw mw mw Tble 2: Power consumption of the Cingulr 2125 smrtphone for different sttes of its network interfces. phone cn be significntly incresed if the Wi-Fi rdio is turned off most of the time. This forms the primry motivtion for our work on Cell2Notify, where we turn on the Wi-Fi device only when it is needed. Figure 3: Our experimentl setup to mesure the bttery power consumption of smrtphone when different network interfces re turned on nd used. difficult to implement nd mnge ny cll hndling system. Given the bove fctors, we conclude tht it is preferble to use Wi-Fi for VoIP insted thn cellulr dt network. 3.2 Smrtphone Power Mesurements We now mesure the power consumption of populr smrtphone, the HTC Torndo (Cingulr 2125). This device hs n ARM TI 195 MHz processor, runs Windows Mobile 5.0 nd hs TI g Wi-Fi chipset. We subscribed to the Cingulr voice pln for our experiments. We mesured the power consumption of the smrtphone for vrious sttes of its network interfces, i.e. GSM nd Wi-Fi, nd we show tht Wi-Fi is mjor power drin if it is in the ON stte t ll times. We lso use these numbers lter to evlute our Cell2Notify protocol. Our experimentl setup to mesure the energy consumption of smrtphone is bsed on the technique described in [10]. We fully chrged the bttery of the smrtphone nd then removed the bttery from the device for n hour. We then connected 0.5 ohm sense resistor in series with the bttery of the device, nd mesured the instntneous current cross the resistor t 50,000 smples per second using dt cquisition system. We illustrte our setup in Figure 3. We repeted this procedure for ech of our experiments. All our experiments lsted five minutes ech. To compute the power consumed by the smrtphone, we multiplied the current with the verge supply voltge of 3.7 Volts. The tlk time for the Cingulr 2125 is rted t 4 hours. With its 1150 mah bttery, this corresponds to power consumption in n ctive cellulr voice cll of 1150*3.7/4 = mw. We present the mesured results in Tble 2. In ech of our experiments, we mesure the totl power consumption of the smrtphone, not just the power consumption of the interfce. We set beming to off, the bcklight timeout to five seconds which is the minimum possible, the disply timeout to 1 minute (lso the minimum possible), the light sensor to off, nd the erpiece volume to the minimum vlue. As we see from this tble, the smrtphone expends very little bttery power to keep its GSM interfce on when it is connected. However, it consumes much more bttery power when its Wi-Fi interfce is on. Note tht the Wi-Fi crd ws using IEEE power sve mode. Even when the Wi-Fi rdio is idle, the device consumes more thn 15 times the bttery power thn in GSM idle mode. These numbers indicte tht the totl lifetime of smrt- 4. CELL2NOTIFY ARCHITECTURE Cell2Notify increses the bttery lifetime of smrtphones by disbling the Wi-Fi rdio when the user is not mking VoIP cll. It enbles the Wi-Fi interfce only when either the user wnts to initite VoIP cll, or when the user is receiving n incoming VoIP cll. In the ltter cse, Cell2Notify sends wke up signl to the smrtphone s ring on the cellulr interfce (either GSM or CDMA). As noted in Section 3.2, the cellulr interfce consumes significntly less energy thn the Wi-Fi interfce when not in use, nd users rrely disble it. Consequently, Cell2Notify results in significnt energy svings when using smrtphones for VoIP over Wi-Fi. The design of Cell2Notify poses two primry chllenges. First, the system needs to be esily deployble. Therefore, it should not require chnges to the stndrdized protocols used by VoIP phones. Furthermore, Cell2Notify cnnot require wholesle chnges to network infrstructures it relies upon neither the Wi-Fi infrstructure nor the cellulr infrstructure. Second, disbling the Wi-Fi interfce should not result in dropped clls nor significnt delys. Cell2Notify must enble the Wi-Fi interfce nd complete the VoIP cll within resonble mount of time. Finlly it must hndle scenrios where the user is n re tht lcks either Wi-Fi or GSM coverge. The Cell2Notify rchitecture ddresses these chllenges by requiring miniml modifictions to the VoIP rchitecture illustrted in Figure 1. Cell2Notify only requires softwre chnges t the VoIP proxy server nd on the smrtphone devices. Furthermore, ll the softwre chnges re implemented t user-level, nd hence re esily deployble. Our prototype system works with the Session Initition Protocol (SIP) [21], which is the most commonly used protocol to set up VoIP sessions. All our chnges t the proxy server re to the SIP proxy s configurtion files, which llows Cell2Notify to be deployed incrementlly. Our system is lso bckwrds comptible in tht it supports users with phones tht do not hve cellulr interfce, though those users will not obtin ny of the energy sving benefits. Our system incurs cceptble cll setup ltencies, nd we devise simple protocols to hndle scenrios where the user is out of rnge of either the cellulr or Wi-Fi network. As shown in Figure 4, our system introduces two new components to n existing VoIP system. We enhnce the VoIP proxy server of trditionl deployment with dditionl cll hndling rules, nd cll it the Cell2Notify Server. The Cell2Notify Server lso mintins tble tht contins the mpping of users (VoIP extensions) to their corresponding cell phone numbers. The other new component in the Cell2Notify system is the Cell2Notify Client, which is trditionl smrtphone running our user-level service. Our service hndles notifictions sent by the Cell2Notify server. We describe our rchitecture in detil in the rest of this section. 182

5 Figure 4: Steps of the Cell2Notify protocol. 4.1 Cell2Notify Protocol The min steps of the Cell2Notify protocol re illustrted in Figure 4. Registrtion, which is not shown in the figure, is required before device cn utilize this rchitecture. In the Registrtion step the network dministrtor dds new smrtphone to use the VoIP system. During registrtion, the Cell2Notify server dds mpping of the smrtphone s VoIP extension to its cell phone number. The server lso genertes unique Cller-ID (UID) tht it will use s the Cller-ID when clling the smrtphone to initite wkeup. The UID is 10 digits long, nd its first digit is set to 0 to prevent collisions with existing phone numbers. This scheme provides bsic security ginst Cller-ID spoofing. Since this UID is rndomly generted nd is different for different extensions, it is not trivil for ttckers to send spurious wkeup clls. We lso present security enhncement to this bsic scheme in Section 7.2. Finlly, the smrtphone is updted to set the VoIP extension nd to store the UID tht will be used by the server to contct it. The Cell2Notify client disbles its Wi-Fi interfce whenever it receives good signl from cellulr bse sttion. When n incoming VoIP cll rrives t the Cell2Notify server (Step 1 of Figure 4), the server looks up the client s extension in its tble nd retrieves the corresponding cell phone entry. The server then initites cll to the client s cell phone number over the PSTN using n ATA (Step 2). When the Cell2Notify client receives this cll, our user-level service trps the Cller-ID, nd checks to see if the Cller-ID mtches the Cell2Notify server s UID. If the Cller-ID does not mtch the service llows the cll to ring on the device s regulr cll. However, if the Cller-ID does mtch the server s UID then the service enbles the Wi-Fi interfce (Step 3). The client ssocites with Wi-Fi Access Point (AP) nd registers its IP ddress with the Cell2Notify server. The server cn subsequently set up the VoIP cll (Step 4), by sending the Cell2Notify client s credentils to the cller. The cll is finlly crried out end-to-end between the two devices without going through the server (Step 5). After the VoIP cll ends, the Cell2Notify client disbles the Wi-Fi interfce. We note tht fter Step 1, if the Cell2Notify server does not find cell phone number corresponding to the client s extension, it simply proceeds to hndle it s regulr SIP server. In other words, it ttempts to set up the cll if the client hs previously registered, nd otherwise it will send bck busy tone. Similrly, if fter Step 1 the Cell2Notify server finds tht the client hs lredy registered, it ttempts to setup the cll s regulr SIP server, i.e. it directly clls the client s VoIP number. 4.2 Connectivity Scenrios Cell2Notify needs to robustly hndle situtions where either the cellulr network or the Wi-Fi network becomes unvilble. In these situtions, our gol is to perform t lest s well s legcy VoIP deployment tht does not use Cell2Notify. In this section, we enumerte the connectivity possibilities nd describe the system behvior in ech of those situtions Registered Client, in Wi-Fi, Cellulr Rnge This is the idel cse for our protocol. The smrtphone is in rnge of known Wi-Fi network nd hs good cellulr coverge. It hs lso previously registered with the Cell2Notify server, nd its DHCP lese hs not expired. Moreover, it hs not moved recently, so it hs cched stte of the nerby APs. When someone clls the client, the Cell2Notify server sends wke-up cll on the cellulr interfce. The smrtphone then enbles its Wi-Fi interfce, connects to the AP whose informtion it hs cched, nd sends SIP register messge to the Cell2Notify server. The server then connects the VoIP cll over the smrtphone s Wi-Fi interfce Unregistered Client, in Wi-Fi, Cellulr Rnge In this scenrio the client is in Wi-Fi zone but hs not yet connected nd registered. In comprison to the previously described cse, there is n extr step involved. Upon receiving the wkeup cll over the cellulr interfce from the Cell2Notify server, the device enbles its Wi-Fi interfce nd performs scn to look for vilble APs. The rest of the steps re similr to the previous scenrio. To ddress this cse, the Cell2Notify server ttempts clls to the client s SIP extension multiple times to llow enough time for the mobile device to look for vilble Wi-Fi APs Client in Cellulr Rnge, out of Wi-Fi Rnge We now consider the cse where client is not in Wi-Fi zone. When the Cell2Notify server sends wke-up cll over the cellulr interfce, the device enbles the Wi-Fi interfce nd scns for wireless networks. Since there is no wireless network vilble in this cse, the Cell2Notify client never sends SIP register bck to the Cell2Notify server nd eventully turns its Wi-Fi interfce off to sve power. To hndle this scenrio, we use reltively long timeout vlue t the proxy. If the proxy cnnot connect the cll to the mobile device it hs severl options. Bsed on user preference, it cn either forwrd the cll on the regulr cellulr line fter resetting the Cller-ID to the correct Cller-ID (not the UID), or it cn request tht the cller leve voicemil. The first option will complete the cll, lthough the cll setup will incur extr ltency equl to the timeout vlue of the SIP server. These options cn be configured s prt of the cll hndling rules (described in Section 4.3) for the VoIP extension of the smrtphone, nd cn be customized bsed on user preference Client out of Cellulr Rnge Cell2Notify is bsed on two key properties of the cellulr networks: low power consumption of the cellulr rdio nd ner ubiquitous connectivity. However in the rre cse tht there is no cellulr coverge, our user-level service on the smrtphone utomticlly enbles the Wi-Fi interfce nd registers with SIP on the Cell2Notify server. At this point, the Wi-Fi interfce only uses IEEE power-sve mode [12] to sve energy. As soon s the Cell2Notify client detects cellulr coverge, it sends SIP deregister messge nd turns off its Wi-Fi interfce. At this point 183

6 it reverts to using Cell2Notify wkeups on its cellulr interfce to enble its Wi-Fi interfce Client Mobility Mobility cn cuse client to move in or out of cellulr or Wi- Fi coverge. This cn led to window of vulnerbility where the stte of the client my be different from wht is known t the SIP server. For exmple, when client moves into cellulr coverge, it disbles its Wi-Fi interfce, lthough the SIP server might hve initited the signling of n incoming cll on the client s Wi-Fi interfce. To hndle these mobile scenrios, Cell2Notify requires the SIP server to simultneously ring the cellulr interfce of the device while sending SIP invittion on the client s Wi-Fi interfce. So, even in the bove scenrio, when client moves into cellulr coverge, nd disbles its Wi-Fi interfce, the cll setup is successful. In the other scenrio where client moves out of cellulr coverge, it immeditely enbles its Wi-Fi interfce, nd sends SIP register messge to the SIP server. Therefore, in this cse, the ltency is better thn if the device ws in cellulr coverge. Finlly, we note tht the problem of hndoff cross Wi-Fi APs when VoIP cll is in progress, is out of scope for Cell2Notify, which is signling protocol for VoIP cll setup. 4.3 Modifictions to the VoIP Server The bove steps cn be implemented over SIP, without significnt modifictions to stndrd VoIP proxy server. To implement Cell2Notify, we only need to dd cll hndling rules for ech VoIP extension or user nme tht is registered with the Cell2Notify server, nd no source code modifictions to the VoIP proxy re needed. This rule-bsed cll hndling is implemented by mny commercil SIP/VoIP proxies [31]. The set of SIP rules t the Cell2Notify server re s follows: 1. Send ring tone to cller. 2. Mke cll to cllee s registered cell phone. 3. Dil the VoIP extension of cllee. Retry fter timeout. 4. Wit few seconds for cllee s response. 5. Send invlid tone to the cller if no response from cllee. 6. Hng up if no response from cllee is forthcoming. In Section 5, we present the specific cll rules we used in our prototype for the Asterisk SIP server. Step 1 informs the cller tht the cll is being hndled. Step 2 tells the cllee to enble its Wi-Fi interfce nd complete the cll. Step 3 ttempts to connect to the cller. The server retries this step few times to ccount for vrition in the time tken by the cllee to ssocite nd uthenticte with the AP, nd obtin n IP ddress using DHCP. Step 4 wits little longer for response. If there is no response from the cllee, the server sends bck n invlid tone to the cller (or voice milbox of the cllee) in Step 5 nd hngs up the cll in Step 6. Since these chnges re just rules dded to the configurtion file of the SIP server, Cell2Notify cn be esily dded to n existing VoIP deployment without dding ny new servers or chnging the infrstructure. Furthermore, Cell2Notify works within deployments tht hve VoIP phones without cellulr interfce, or where some users prefer not to use Cell2Notify. Therefore, our system is incrementlly deployble s well s bckwrds comptible. 4.4 Modifictions to the Smrtphone We require few chnges to the smrtphone devices, yet ll these chnges cn be implemented reltively esily. We need the following dditionl fetures: (i) The bility to distinguish wke-up cll from regulr cll over the cellulr interfce. (ii) The bility to power on the Wi-Fi interfce. (iii) The bility to control ssocition nd uthentiction with Wi-Fi network. (iv) The bility to monitor trffic over the Wi-Fi interfce to power it off utomticlly t the end of VoIP cll. As described in Section 4.1, the Cell2Notify server sends unique ID (UID) to the mobile device s prt of the registrtion process. The component of the smrtphone tht hndles incoming clls needs to be modified to check the Cller-ID of ll incoming clls ginst this UID. In cse of Windows Mobile bsed smrtphone this cn be done by modifying the connection mnger. When the incoming Cller-ID does not mtch the UID, the incoming cll is treted s regulr cll. When the incoming Cller-ID does mtch the UID, the connection mnger tkes the following steps: 1. Do not send the cll notifiction to the user. 2. Power on the Wi-Fi interfce. 3. Authenticte nd ssocite to the Wi-Fi network nd request n IP ddress from the DHCP server. 4. Strt up the SIP softphone user interfce. 5. Send SIP register messge to SIP proxy with the destintion ddress s the IP ddress cquired from the Wi-Fi network. When the Cell2Notify server receives the SIP register messge from the smrtphone device, it cn complete the SIP cll. An importnt point to note is tht the Cell2Notify server is not required to keep ny stte, since the SIP cll is completed over the Wi-Fi interfce of the mobile device nd the voice session (using RTP) is estblished end-to-end. This mkes our system highly sclble. Once the VoIP cll ends, the smrtphone must detect this event nd turn off the Wi-Fi interfce to sve energy. This my be complicted given the presence of other trffic on the Wi-Fi interfce, in which cse it my not be cler tht the cll hs ended. To detect the end of VoIP cll, we hve implemented n ctivity detector tht monitors the wireless interfce for dt sent nd received. Although VoIP sessions generte n lmost constnt quntity of dt trffic during the lifetime of session, the ctul quntity of trffic is dependent on the codec used. Therefore, utomticlly distinguishing VoIP from other trffic is very difficult. Insted, our detector simply uses conservtive pproch, powering off the Wi-Fi interfce fter full ten seconds of network inctivity (lthough the intervl length is configurble). 4.5 Other Applictions Until now we hve focused on using Cell2Notify solely for VoIP clls. However, this rchitecture cn be used to enble number of other services for smrtphones. For exmple, the Cell2Notify server cn be configured to send e-mil notifictions by using different Cller-ID. The Cell2Notify client cn use the Cller-ID to differentite between VoIP nd e-mil notifictions. The smrtphone cn then connect to the mil server over Wi-Fi to downlod the e-mil messge contents. Becuse mny people receive much lrger number of incoming e-mils thn phone clls, our notifiction system my impose much lrger lod on the cellulr network. To void this overlod, we cn tune the Cell2Notify server to only send these notifictions for high priority e-mils, or for e-mils from pre-specified group of people. 184

7 A similr ppliction tht cn benefit from Cell2Notify is Fx over Wi-Fi. Any existing scheme for sending Fx over IP, such s T.38 [19], requires the Wi-Fi client to be enbled nd hence drins bttery power. With Cell2Notify, the Wi-Fi client cn be disbled most of the time, nd enbled only to receive the fx trnsmission. Cell2Notify lso hs pplictions outside the enterprise setting. For exmple, ny VoIP provider, such s VoIP-User or Skype, cn use Cell2Notify to notify their users of incoming clls t home. They would only dditionlly need the cell phone numbers of smrtphones tht would be used s receivers of the VoIP clls. In similr vein, cell phone providers such s T-Mobile, who re moving towrds UMA [29] could benefit from Cell2Notify. UMA llows cell phone to use Wi-Fi connection if vilble. However, the Wi-Fi device lwys needs to be enbled to receive incoming clls. Using Cell2Notify, they cn disble the client s Wi-Fi device unless the client is either receiving cll or mking one. 4.6 Alterntives to Cell2Notify There re severl lterntives to Cell2Notify. In this subsection we use three metrics to rgue tht notifictions using cll over the cellulr network is better pproch. The three metrics re: cost, deploybility, nd performnce. One lterntive to Cell2Notify is Wke-On-Wireless [23]. This scheme requires custom low power rdio to be dded to ech smrtphone, s well s to the enterprise wireless infrstructure. When user receives cll, Wke-On-Wireless(WoW) sends signl to the smrtphone using the low power rdio to enble the Wi-Fi interfce. This scheme is more costly s this requires the deployment of other low power rdios, nd is lso less deployble since it requires hrdwre chnges on ll the smrtphone devices. Ondemnd pging [1] hs the sme gol. It requires Bluetooth hrdwre to be dded to ech AP. On receiving cll, the AP sends signl vi Bluetooth to the smrtphone to enble the Wi-Fi device. Since smrtphones mostly hve Bluetooth interfce, this scheme is more deployble thn WoW. However, it too requires chnges to the infrstructure nd is therefore costly. Furthermore, both Wke-On-Wireless nd On-Demnd Pging suffer from the rnge mismtch problem: the different wireless interfces hve different coverge rnges, nd the low-power wireless interfce typiclly covers smller region thn the Wi-Fi interfce. Therefore, the dditionl wireless infrstructure must be deployed t higher density thn the existing Wi-Fi deployment of ccess points. Another pproch to Cell2Notify would be to use n SMS (Short Messging System) bsed notifiction system. This scheme is similr to ours except tht it would send n SMS messge to the smrtphone over the cellulr network. Although this scheme is s chep nd deployble s Cell2Notify, it suffers from poor performnce. SMS usully incurs higher ltency nd is more unrelible thn phone clls. This reduces the usbility of this system. 5. PROTOTYPE IMPLEMENTATION We re currently implementing the Cell2Notify system on Windows CE, commonly used operting system on smrtphones. In the mentime, for evlution purposes, we hve built prototype of Cell2Notify using commonly vilble off-the-shelf components. The components of our prototype re illustrted in Figure 5. We implement the Cell2Notify server using combintion of the opensource Asterisk SIP Server [3] nd the VoIP gtewy provided by Junction Networks [13]. We emulte smrtphone using combintion of cell phone nd lptop running Windows XP. We use Sony Ericsson W810i cell phone with built-in Bluetooth interfce. The lptop lso hs built-in Bluetooth, nd we use Netger WAG511 Crdbus crd s the Wi-Fi interfce. Finlly, we use Figure 5: Our prototype implementtion of Cell2Notify. We implement the Cell2Notify server s combintion of commonly vilble SIP Proxy nd n Internet- bsed VoIP gtewy. We emulte smrtphone using combintion of cellphone tht communictes with Wi-Fi equipped lptop using Bluetooth. populr SIP client for Windows XP clled X-Lite [7] s the VoIP softphone. Our prototype requires miniml modifictions to the bove components. We mde chnges to the cll hndling configurtion files of the SIP server, nd we built user-level cll-mnger service tht runs on the Windows XP lptop. Our prototype demonstrtes the ese with which Cell2Notify cn be incrementlly deployed in n existing VoIP system. Although our prototype is not the idel implementtion of the Cell2Notify rchitecture, it serves to demonstrte working system nd it is useful for evlution of our rchitecture. The steps of the Cell2Notify protocol for our prototype re shown in Figure 5. When someone mkes incoming cll to Cell2Notify client, the Asterisk SIP Proxy looks up the corresponding cellulr number for the client, nd mkes cll to the client over PSTN using the Junction Networks gtewy. When our cellphone receives the cll, it notifies the lptop of the incoming cll vi Bluetooth. The cll-mnger service on the lptop then turns on the Wi-Fi interfce nd uses it to connect the cll. When the cll is complete, the cll-mnger turns off the Wi-Fi interfce. In the rest of this section, we describe the implementtion detils of the Cell2Notify server nd client components. 5.1 Prototype Cell2Notify Server The Cell2Notify server only requires miniml modifictions to the Asterisk SIP Server. We hve dded mpping from SIP extensions to the corresponding cell phone number, nd set of cll hndling rules for ech registered Cell2Notify client. Asterisk supports integrtion with bck-end dtbse, thus llowing the cell phone mpping tble nd cll hndling rules to be implemented s seprte tbles in the dtbse, nd be linked to the Asterisk server. Presently we hve mnully dded these mppings for ech Cell2Notify client to the Asterisk configurtion files. However, this tsk cn be esily utomted using the supported dtbse functionlity. We implement the steps described in Section 4.3 s cll hndling rules in the Asterisk server. We define these rules for every registered extension or user nme. To define the cll hndling rules, we use generic functions tht re supported by most SIP proxies, such 185

8 s Ringing, Plybck, Dil, Wit nd Set(CALLERID).TheRinging function sends bck ring notifiction to the cller. Plybck plys defult welcome messge nd Dil dils SIP extension. The Wit function wits for specified durtion before executing the next rule. Set(CALLERID) is interesting s it llows the Cller-ID of the outbound cll to be set to n rbitrry number. In the following exmple, we present the cll hndling rules for prticulr extension, sy extension 7676: 1. exten => 7676,1,Ringing 2. exten => 7676,2,Set(CALLERID(number)= UID) 3. exten => 4. exten => 7575,4,Wit(2) 5. exten => 7676,5,RetryDil(witing 1 8 SIP/ Ttm) 6. exten => 7676,6,Plybck(Invlid) 7. exten => 7676,7,Hngup These rules define the steps executed by the Cell2Notify server when there is n incoming cll for extension The first rgument denotes the destintion extension (7676) for the incoming cll, the second rgument is the rule order(1,2,..,7), nd the third denotes the function (Dil, Ringing, etc.). Rule 1 executes the Ringing function nd sends bck ring tone to the cller. The server then looks t Rule 2 nd executes the Set(CALLERID) function with the UID s prmeter, essentilly setting the Cller-ID to the UID for the next outbound cll. As explined erlier the UID is different for ech smrtphone client using Cell2Notify nd is negotited during registrtion. Rule 3 plces cll to the prticulr cellulr number ssocited with extension 7676 using the Junction Networks gtewy. Rule 3 is essentilly needed to send signl to the Cell2Notify client to turn on its Wi-Fi interfce. In rule 4 the server executes Wit for 2 seconds to insert some dely before trying to contct the extension. On encountering rule 5 the server executes Dil to contct the SIP extension 7676 repetedly 8 times with 1 second intervl between subsequent retries. These retries re needed becuse of the ltency to turn on the Wi-Fi interfce on the lptop device, nd the ltency to ssocite nd uthenticte over the Wi-Fi network. In the cse where cll is not connected or remins unnswered the server executes the Plybck function s specified in rule 6, to send the cller n invlid extension or unrechble messge. According to Rule 7, the server executes Hngup to end the cll. Rule 6 could be modified to plybck nother messge, record voice mil, forwrd the cll to nother extension, or even forwrd the cll to the cellulr number of the user. When cll hndling rule (such s Rule 3) requires the server to plce cll on the regulr telephone network, it uses n ATA or n externl third prty VoIP provider to bridge the IP bsed network with the PSTN. We hve implemented both these options. In the first option, we used the Sipur ATA [24] nd privtely lesed PSTN line. For the second option, we used the Junction Networks VoIP gtewy. Using n ATA my be preferble for n enterprise, becuse the cll leves the IP network within the enterprise itself. However, using third prty VoIP provider my be cheper. An rchitecturl requirement for the Cell2Notify server is the bility to plce cll over the PSTN using n rbitrry Cller-ID. We implement this using the Set(CALLERID) function of Asterisk in conjunction with the VoIP gtewy of Junction Networks. The SIP server sets the desired Cller-ID s prmeter to the Set(CALLERID) function. Junction Networks llows users to provide their own Cller-IDs for outgoing clls, s long s it is ny 10 digit number, nd then plces cll to the destintion PSTN number with this Cller-ID using n ATA locted in the Junction Networks dt center. We re currently working on implementing this functionlity on the Sipur ATAs. We discuss the implictions of Cller-ID spoofing in Section Prototype Cell2Notify Client We now describe the implementtion of the Cell2Notify client, focusing on three min chllenges. First, we need wy to signl n incoming cll on the Sony Ericsson cell phone to the cll mnger service on the Windows XP lptop, nd we need to send the Cller-ID of the incoming cll to the cll mnger. Second, we need minimize the dely in completing the cll by reducing the dely imposed by the Wi-Fi uthentiction nd ssocition process. Finlly, the cll mnger service needs to determine when the cll ends nd disble the Wi-Fi interfce. We ddress the first chllenge without requiring modifictions to the Sony Ericsson hndset by configuring the Bluetooth interfce on the lptop to pper s Bluetooth hedset to the cell phone. Consequently, n incoming cll on the cellphone notifies the Bluetooth hedset, which is in fct our lptop. We use Flot Mobile Agent (FMA) [9] to configure the lptop Bluetooth interfce to pper s hedset device. FMA is powerful phone editing softwre which hs extensive support for Sony Ericsson hndsets, including rich set of APIs to control the hndset. One feture of these APIs hndles Cll-Notify event which our cll mnger service uses to trp n incoming cll. We built seprte cll hndler on the FMA frmework tht checks the Cller-ID of ech incoming cll to see if it is from the Cell2Notify server, bsed on the unique ID tht ws exchnged s prt of the registrtion process. FMA lso provides wy to disconnect cll. If the Cller-ID mtches tht of the Cell2Notify server, the cll hndler disconnects the cll nd wkes up the Wi-Fi interfce. If the Cller-ID does not mtch, the cll hndler lets the cll through nd ring on the hndset. To ddress the second chllenge, our service uses cching to quickly ssocite with n Access Point nd complete the cll over Wi-Fi. When wireless crd is enbled, it usully goes through series of steps before it obtins vlid IP ddress. For exmple, it scns the network looking for the best vilble AP, fter which it performs the entire ssocition procedure. Associting with n AP using the stndrd Windows XP Zero Configurtion Service tkes multiple seconds [6]. We optimize this step by cching the frequency chnnels of the most commonly used APs. We lso turn off the Zero Configurtion Service nd implement tools to control the wireless interfce from our own Cell2Notify service. When the Wi-Fi interfce is turned on, we instruct the crd to go to specific chnnels nd ttempt ssocition to the wireless network. We hve mesured the totl time to ssocite on given chnnel to be less thn 20 ms for the Netger WAG511. Using this optimiztion, we re ble to complete the ssocition within few hundred milliseconds, s shown in Section 6. Once the Wi-Fi crd is enbled nd hs n IP ddress, we strt the X-Lite SIP client. The SIP client sends register messge to the Cell2Notify server with its cquired IP ddress nd completes the cll over Wi-Fi. Finlly, we need wy to utomticlly detect the end of VoIP cll nd turn off the Wi-Fi interfce. After the Wi-Fi interfce is enbled, our cll mnger service enters n ctivity monitoring mode. In this mode, it checks the number of pckets sent nd received on the Wi-Fi interfce. It does not immeditely disble the Wi-Fi interfce when the number of pckets is zero, s this might disconnect the cll during period of silence. Insted, the service uses some 186

9 s ) 60 te u50 in (M 40 ls C30 f o n 20 tio 10 r u D s ) 60 te u in 50 (M 40 ls C 30 f o 20 n tio 10 r u D s ) 60 te u 50 in (M 40 ls C 30 f o n 20 tio 10 r u D Hour of the Dy Hour of the Dy Hour of the Dy () Jmes s Office Phone (b) John s Cell Phone (c) Beth s Cell Phone Figure 6: Cll logs of three users. Jmes is n employee in n enterprise, nd the heviest office phone user mong five employees we studied. John is moderte cell phone user, nd Beth is n extremely hevy cell phone user. She mkes clls t 3 AM, nd receives cll t 8AM. hysteresis nd only disbles the Wi-Fi interfce if there re no pckets sent over it for certin number of seconds. We experimented with vrious vlues nd found tht dely of ten seconds ws dequte. To void modifictions to the SIP client ppliction code, we terminte the SIP client process t the end of cll nd restrt it when new cll is initited or received. 5.3 Is the Prototype Rel? We hve built nd demonstrted working Cell2Notify prototype. One obvious concern is the prcticlity of our system, given tht we hve emulted the Cell2Notify client rther thn implementing it on rel smrtphone. We rgue tht ll our chnges cn be esily migrted to smrtphone. The Bluetooth notifiction from the cell phone to the lptop will not be required when the GSM nd Wi-Fi interfce re on the sme device. Our cll hndling routines would lso be simpler on smrtphone, nd we would not need the APIs provided by FMA. For exmple, on smrtphone running Windows CE the only modifiction required is to the Connection Mnger on the smrtphone device to implement the cll hndling functionlity. Chnges to enble nd disble the Wi-Fi interfce cn lso be esily migrted to the smrtphone. In fct, we expect even better performnce on smrtphones since the SIP client will lwys be running on it, s compred to our prototype where we hve to terminte nd restrt the X-Lite SIP client process. 6. SYSTEM EVALUATION The utility of mobile device is directly relted to the useful operting lifetime before its bttery needs to be rechrged. Thus, the primry metric we use to evlute our Cell2Notify system is the reduction in energy consumption, which directly trnsltes to incresed bttery lifetime. We lso evlute the increse in endto-end ltency tht cller experiences when mking cll to Cell2Notify client. Our results show tht using Cell2Notify, users cn gretly increse the totl usge lifetime of their Wi-Fi enbled smrtphones when using VoIP, while experiencing only nominl increse in initil cll-setup ltency. 6.1 Reduction in Energy Consumption To quntify the energy svings enbled by Cell2Notify, we first mesured the power consumption of vrious commonly used wireless crds. The stndrd [12] specifies vrious modes of opertion for the interfce but not the specific implementtion detils. Tble 3 below illustrtes the power consumption of severl Wi- Fi interfces in the norml mode of opertion, Awke Mode(AM), nd the low power mode clled Power Sve Mode (PSM), chieved by duty cycling the wireless interfce. The Cisco PCM-350 is sometimes referred to in reserch literture for the ske of comprison, lthough it is known to be quite power inefficient. The Netger MA701 nd Linksys WCF12 crds re the most power efficient mong the crds tht we hve mesured nd thus we use the Linksys WCF12 s bseline for comprison. Once enbled, Wi- Fi interfce usully tkes some time to stbilize, before reching stte where it cn perform ctive dt trnsfer. Similrly, when disbling Wi-Fi interfce it tkes some time before the power drwn by it becomes negligible. In ddition to mesuring the power consumption of these wireless crds, we hve lso mesured the power consumption of Windows Mobile bsed smrtphone. The power consumption for the Cingulr 2125 ws reported in Section 3.2 erlier. Vendor Averge Power Idle(AM) Idle (PSM) Active Cisco PCM mW 390mW 1600mW Linksys WCF12 690mW 256mW 890mW Netger MA mW 264mW 990mW Tble 3: Mesured power consumption for b crds The effective energy svings for prticulr user re somewht dependent on their usge ptterns. As stted erlier, our Cell2Notify scheme keeps the Wi-Fi interfce of smrtphone switched off t ll times, except during n ctive VoIP cll. Thus, user who uses their phone for spordic converstions will end up sving more energy, in contrst to hevy user who communictes more frequently. Energy sved by our low power rchitecture is thus directly dependent on the mount of idle time experienced by mobile device. In order to study typicl usge ptterns, we gthered detiled cellulr phone cll-logs of different users. Using these cll logs we construct similr trce of periods of communiction ctivity nd inctivity, tht would be experienced if the users were using VoIP over Wi-Fi insted. Using these cll trces we ccurtely estimte the level of energy svings enbled by the Cell2Notify rchitecture. We then compre this to the energy consumption of these devices, if they were using the stndrd operting modes, AM nd PSM respectively. This technique of using cll-logs is similr to the one used in Wke-on-Wireless [23]. Figures 6(), 6(b) nd 6(c) show the clling ptterns of users Jmes, John nd Beth respectively. Jmes is rel employee in n enterprise nd is the heviest user mong five of his collegues in our study group. John is light user with n verge tlk time of bout 5 minutes per hour. Beth on the other end is hypotheticl 187

10 Energy (in KJoules) Netger MA701(PSM) Linksys WCF12 (PSM) Beth John Jmes Cell2Notify ) s c e s i n ( y c n e t L Prototype Ltency SIP Register+Subcribe+Notify Enble VoIP Client & Obtin IP Connect to AP Enble Wi-Fi interfce Cll on Cellulr Interfce Expected Ltency Figure 7: Energy consumption using two crds, with nd without Cell2Notify for three different users. Cell2Notify sves more energy for lighter usge ptterns. ) 70 e g 60 s U f 50 o r s u40 o ( H30 e 20 t im ife 10 L 0 Using WiFi Using Cell2Notify Beth John Jmes Figure 8: Energy consumption of Cingulr 2125 with nd without Cell2Notify for three users. We ssume tht the user does not use the smrtphone for ny other purpose, but only for mking nd receiving VoIP clls. person with reltively hevy usge pttern, with n verge tlk time of 15 minutes per hour. On the horizontl xis, the hour of the dy is shown rnging from 0 hours to 23 hours. The totl number of minutes tht user ws ctively communicting over the phone re mrked on the verticl xis. The different shded subsections for ech verticl column depict the number of clls mde in tht hour nd the durtion of ech cll. These cll logs re illustrtive trces tht helpevlute theestimted energy svings for these three usge ptterns. Figure 7 plots the totl communiction energy consumption for the vrious users clling ptterns in 24 hour period. The grphs shows the energy consumed in the wireless interfce when two low power Wi-Fi crds (MA701, WCF12) re used, compred to the energy consumption when utilizing the Cell2Notify rchitecture. As cn be seen even Beth, with hevy usge pttern, cn sve up to 47% of the energy consumption compred to using the Wi-Fi crds in the Power Sve Mode (PSM). John nd Jmes, who hve lighter usge ptterns end up sving 70% nd 87% respectively of the energy consumed compred to using the Netger MA701 in PSM mode. In essence, lowering the energy consumption leds to longer bttery lifetime of smrtphone. To quntify the effects of our scheme in terms of incresed lifetime we mesured the power consumption Figure 9: Brekdown of vrious steps of the Cell2Notify protocol in cll-setup ltency. The right br shows the expected ltency with our proposed optimiztions. Even without optimiztions, the extr dely is round ten seconds, which is less thn two rings. of Wi-Fi enbled Smrtphone (Cingulr 2125) in vrious modes of opertion. Using our detiled power mesurements reported in Section 3.2 nd the rted cpcity of the phone bttery (1150 mah), we determine bttery lifetime. Figure 8 shows the increse in bttery lifetime for the three usge scenrios. Our bse comprison is using the Wi-Fi in lwys on mode for the smrtphone. As cn be seen Beth experiences 70% increse in bttery lifetime by using Cell2Notify. John nd Jmes on the other hnd experience 230% nd 540% increse in lifetime, primrily becuse of their light usge ptterns. 6.2 End-to-End Ltency The reduction in energy consumption when using the Cell2Notify rchitecture hs n ssocited trdeoff with respect to the dded ltency in connecting VoIP cll. Since the mobile device tht is the end recipient of the VoIP cll hs its wireless interfce switched off, there re multiple steps tht hve to be tken before the device cn ctully ccept the cll over Wi-Fi. Ech of these steps hs n ssocited ltency overhed. In this section we evlute these ltencies for our prototype implementtion. We lso provide detiled mesurements of these ltencies for other pltforms. Some of the ltencies re fixed costs which re beyond our control, for exmple the time tken to connect cll over the cellulr network, while some of the other ltency components cn be optimized. Using these mesurements we cn provide resonbly ccurte estimte of the lower bound on the totl end-to-end ltency tht device using our rchitecture experiences. Cell2Notify Protocol Step Ltency (in seconds) Stndrd Dev. Mx Vlue Cll on GSM Enble Wi-Fi Connect to AP Enble VoIP Client Obtin IP Address SIP Opertions Tble 4: Stndrd devition nd mximum vlues for vrious steps of the Cell2Notify protocol. Note tht the steps Enble VoIP Client nd Obtin IP Address occur in prllel. 188

11 Figure 9 shows the brekdown of the cll-setup ltency introduced by vrious steps of the Cell2Notify system. The br on the left in the figure shows the ltencies mesured on our prototype implementtion using the combintion of Windows XP lptop nd n SE-810i cellulr phone. The column on the right shows the expected ltency for the cse of finl product implementtion on smrtphone. Ech ltency vlue presented in the Figure is n verge over minimum of ten runs. We present the stndrd devition nd mximum vlues for ech of these steps in Tble 4. Our mesurements show tht the verge dded ltency for our prototype implementtion is round ten seconds. This extr wit is equivlent to two rings received by the cller. We believe this overhed is miniml nd cceptble in most scenrios. Furthermore, we expect rel smrtphone nd enterprise deployment of Cell2Notify to incur n overhed of round seven seconds, which will provide more semless experience to users of Cell2Notify. A big chunk of the overhed is the time tken by the SIP server to cll the GSM interfce of the Sony Ericsson cell phone. It is difficult to ccurtely quntify this overhed, since the cller (server) nd cllee (Sony Ericsson hndset) re on two different mchines. We used stopwtch to mesure this time for over 20 runs, but we re wre of possible inccurcies due to humn rection times. However, we note tht our rection times will likely result in n overestimte of the ltency. As we see in Figure 9, the time tken for the Cell2Notify server to cll the GSM interfce of the Sony Ericsson phone is round 3.7 seconds in our prototype. A lrge portion of this overhed seems to be the time tken to cll Junction Networks, nd for Junction Networks to mke long distnce cll to our cell phone. To estimte the time it would tke in rel prototype, we tested clling locl cell phone number using the Sipur [24] ATA tht we hve set up in our lb. We note tht this time ws only 2.5 seconds. Since most enterprises will hve their privte VoIP gtewy, this seems to be resonble estimte in rel prototype. We further explored the lower bound of this dely when the VoIP gtewy is on the enterprise LAN. We plced clls from the SIP server to the client phone through the Junction Networks VoIP gtewy, nd for different types of client phone connections. We plced 10 clls for ech connection type, nd present the distribution of the time tken to plce these clls in Tble 5. We note tht it tkes n extr second to plce cll to the GSM phone, nd the connection qulity of the phone does not dd significnt ltency. Furthermore, it tkes much lesser time to plce cll on the CDMA phone. This ltency is comprble to the time tken for plcing cll to the lnd line phone, which is round 2.4 seconds. Client Phone (Signl) Ltency (in seconds) Avg. Std Dev. Mx. GSM Cingulr (Excellent) GSM Cingulr (Poor) CDMA Verizon (Fir) Lndline Phone Tble 5: Distribution of time tken by the SIP server to ring phone for vrious connection types. We present the ltency to ring lnd line number s reference. Our optimiztion of using cched Access Point BSSIDs gives good results. Our Cell2Notify client is ble to ssocite with the AP in less thn 200 ms. We used three different APs on three different frequency chnnels in our experiments. We disbled the crd nd rndomly picked n AP to ssocite with in ech run. We lso mesured the defult time to connect to n AP without our optimiztion of cching the AP informtion resulting in much higher overhed, between 3 nd 4 seconds in ech run. This ltency is expected since without our optimiztion, the wireless crd goes into scn mode. It stys for over 100 ms in ech chnnel (ll nd g chnnels), nd only then ssocite with the best AP. Another significnt ltency in Cell2Notify is the time to obtin n IP ddress nd bring up the softphone. As shown in Figure 9 this overhed is round 5 seconds in our prototype. Although it only tkes bout 2.5 seconds to obtin the DHCP ddress, the totl time to strt the X-Lite SIP client process tkes round 5 seconds. As mentioned erlier, we hd to restrt the SIP client process to void modifictions to the SIP client code. In n ctul implementtion over smrtphone, we do not expect this rtificil overhed of restrting the SIP client to be present. Insted, the only overhed should be the time required to obtin vlid IP ddress. After the softphone hs initilized nd obtined vlid IP ddress it sends SIP Register messge, nd Subscribe messge to the Cell2Notify server, which together tke less thn 0.5 seconds. Once the server receives the SIP register from the Windows XP SIP client, it connects the cll. These steps hve very low overhed. Finlly, we note tht since most users re willing to tolerte up to five rings (25 seconds) fter cll connection to rech the voice mil, the less thn ten seconds (2 rings) dely introduced by Cell2Notify is cceptble in most scenrios. Idelly user study would be useful to estimte the ctul impct of this increse in ltency. We pln to investigte this s prt of our future work. 7. DISCUSSION We now discuss vrious issues in the design of Cell2Notify. We first discuss the leglity of our pproch, nd show how our system cn be secured ginst spoofed Cller-IDs. We then discuss the concerns tht cellulr opertors my hve to the deployment of Cell2Notify. 7.1 Is Cller-ID Spoofing Legl? There is no lw in the US ginst Cller-ID spoofing [30]. Cller- ID over PSTN is sent using the SS7 signling protocol. Before the dys of VoIP, expensive equipment ws required to spoof Cller-ID. With VoIP, one cn introduce fke Cller-ID informtion when pssing the cll from IP to PSTN. There re number of commercil services [26,27] tht llow users to mke clls from spoofed Cller-ID. This hs led to few buse cses of pretext clls, where people pretend to be someone else to extrct privte informtion [30]. Therefore, in recent development, the FCC is investigting the use of Cller-ID spoofing for frudulent purposes. However, since Cell2Notify does not ttempt ny frudulent ctivity, we do not expect it to be ffected in the ner future. 7.2 Hndling Spoofed Cller-IDs Given tht Cller-ID spoofing is legl in some countries such s the US, we need to protect ginst ttckers who might spoof the Cller-ID of the Cell2Notify proxy cusing the smrtphone to enble the Wi-Fi crd nd wste bttery power. We cn thwrt this ttck by uthenticting the Cell2Notify proxy t the client using stndrd cryptogrphic techniques. One wy to chieve this is to use the S/KEY system [11], which originted from Lmport s scheme [17] s follows. The Cell2Notify proxy shres different secret key with ech VoIP user, which is set up during secure registrtion. The first Cller-ID used by the proxy is the lst nine digits of one-wy hsh pplied n times over the secret key, where n is lrge number. The first digit of the Cller-ID is set to 0 to void collisions with PSTN phone number. The subsequent Cller-ID is n n 1 times one-wy hsh of the secret key, nd so on. The 189

12 Cell2Notify client uthentictes the proxy by pplying the one-wy hsh on the Cller-ID to see if it mtches the previous Cller-ID. Given strong hsh function, this scheme cn provide resonble protection ginst spoofed Cller-ID ttck. 7.3 Concerns of Cellulr Opertors Cellulr opertors hve vlid reson for blocking the Cller- ID of the Cell2Notify server. After ll, Cell2Notify only uses their network s signling chnnel. Consequently, cellulr opertors do not stnd to gin by llowing Cell2Notify. We hve severl resons to believe tht cellulr opertors might be willing to llow Cell2Notify to mke signling clls over their network. Cell2Notify imposes little lod on their network s for every incoming cll to the VoIP phone, we mke one signling cll over the cellulr network which does not lst more thn few seconds. Even ssuming tht the VoIP phone hs similr usge chrcteristics s the cellulr phone (in Section 6 we show in fct tht n enterprise phone is used quite infrequently), ring for every incoming cll imposes little extr overhed. Furthermore, users might be willing to py n extr connection chrge to chieve longer bttery lifetime. In some cses, the enterprise my be willing to py flt fee to cellulr opertors to support this service. We lso believe this work is extremely timely given the lunch of T-Mobile s UMA service [29]. Cellulr opertor s supporting UMA [14] cn provide Cell2Notify service s n dditionl selling point. Finlly, we note tht it might be techniclly infesible for cellulr opertors to block clls from the Cell2Notify server, since the proxy uses different Cller-ID ech time it sends signl using the mechnism described in Section RELATED WORK Severl projects hve investigted techniques to optimize the energy consumption of the Wi-Fi interfce in bttery powered mobile devices. These techniques rnge from protocol optimiztions in vrious lyers of the networking protocol stck for single Wi-Fi rdio bsed systems, to techniques tht leverge multiple rdios on the sme device. In the cse of systems bsed on single Wi-Fi rdio, reserchers hve explored vrious optimiztions t the ppliction lyer [8, 16], trnsport lyer [5] nd MAC Lyer [15, 32]. However, s we hve shown erlier, the power consumption for Wi- Fi in the lowest power mode (PSM) is still quite substntil even when the device is idle. Cell2Notify, in contrst proposes the use of long rnge cellulr rdio, which hs n order of mgnitude less power consumption thn Wi-Fi PSM, to notify Wi-Fi smrtphone of n incoming cll. Tking into ccount the high idle power of Wi-Fi, the ide of using second lower power rdio to wke-up higher power rdio, hs been proposed [1,23]. Wke-on-Wireless [23] proposes the use of second specil-purpose rdio tht serves s wke-up chnnel for Wi-Fi rdio. The uthors hve proposed PDA bsed phone usge scenrio for their system, similr to Cell2Notify. However the choice of the short rnge custom rdio necessittes multiple intermedite proxies nd presence servers in order to notify the PDAphone of n incoming cll. On-Demnd-Pging [1], builds on the ide of [23], to use commodity Bluetooth rdio present on mobile devices to serve s low power pging chnnel for Wi-Fi. The primry difference between our scheme nd both Wke-On-Wireless nd On-Demnd-Pging is our design choice to leverge the much longer rnge cellulr rdios compred to their choice of short rnge rdios. This hs two importnt dvntges. First, since Cell2Notify uses cellulr rdios with lmost ubiquitous coverge, the re of opertion is much lrger. Second, the infrstructure support needed for our scheme is miniml, with only minor softwre modifictions needed t both the client device nd n existing VoIP proxy in terms of cll hndling rules. Comprtively both the bove schemes need substntil dditionl infrstructure support, while still limiting the re of opertion to their region of deployment. Another set of relted work looks t using multiple rdios for ctive dt trnsfer, rther thn just wke-up [4, 20, 25]. Turducken [25] investigtes the ppliction scheduling problem cross heterogeneous subsystems to mximize the bttery lifetime of mobile device. Cell2Notify ddresses different problem of enbling the Wi-Fi interfce only when required for specific VoIP over Wi-Fi scenrio within the context of smrtphone. Another relted work, clled CoolSpots [20], builds on the ides first presented in [4], nd presents lgorithms to opportunisticlly use either the Wi-Fi or Bluetooth interfce to increse the bttery lifetime of device. In res where the device nd the Wi-Fi Access Point re within Bluetooth coverge, CoolSpots uses flow chrcteristics to determine the best interfce to use for the flow. In contrst, Cell2Notify is gered towrds specific VoIP over Wi-Fi ppliction. It uses the second cellulr rdio purely for signling. In fct, Cell2Notify is complimentry to CoolSpots, nd if the smrtphone lso hs Bluetooth rdio, we could use CoolSpots to determine the best rdio (Wi-Fi or Bluetooth) to route the VoIP trffic, fter Cell2Notify hs signled n incoming cll over the cellulr interfce. A very recent industry trend is the convergence of Wi-Fi nd cellulr services, using technology clled Universl Mobile Access (UMA). For exmple, chipset vendor Kineto [14] nd mobile service provider T-Mobile [28] recently tested service tht llows subscriber to mke unlimited phone clls from the home hotspot or T-Mobile hotspots [29]. UMA increses coverge nd reduces the cost for mobile opertors. Our pproch is complimentry to UMA. Devices using UMA could use our protocol to increse the bttery lifetime of dul rdio devices. 9. CONCLUSION In this pper we present new system, clled Cell2Notify,which leverges the cellulr interfce on smrtphone to reduce energy consumption of VoIP over Wi-Fi enbled smrtphones. We quntify the performnce of cellulr dt networks when used for VoIP nd compre these results with Wi-Fi. We conclude tht Wi-Fi consumes less power nd delivers better performnce thn cellulr dt networks. To the best of our knowledge, ours is the first reserch pper to present such mesurements. We present the Cell2Notify rchitecture tht turns the Wi-Fi interfce off when it is not in use. The Cell2Notify Server plces cll on the smrtphone s cellulr interfce to notify the device of n incoming cll. On receiving this notifiction, Cell2Notify turns on the smrtphone s Wi-Fi interfce nd completes the cll over Wi-Fi. Our system works with existing technologies nd requires miniml chnges to n enterprise s VoIP deployment. We hve built prototype of Cell2Notify nd evluted it in detil. We hve shown tht in most cses, Cell2Notify incurs less thn two rings (10 seconds) of cll setup ltency while more thn doubling the verge bttery lifetime of smrtphone. Acknowledgements We thnk our shepherd Mrk Corner nd the MobiSys nonymous reviewers for their feedbck on this pper. We lso thnk Jitu Pdhye for insightful discussions during the design of Cell2Notify, nd Ptrick Verkik nd Sudipt Kundu for their feedbck on the Cell2Notify prototype. We thnk Dvid Cmpbell nd Eric Putnm for helping us with the smrtphone power mesurements. 190

13 10. REFERENCES [1] Y. Agrwl, C. Schurgers, nd R. Gupt. Dynmic Power Mngement Using On Demnd Pging for Networked Embedded Systems. In Proceedings of the 2005 Conference on Asi South Pcific Design Automtion, pges , New York, NY, USA, ACM Press. [2] M. Annd, E. B. Nightingle, nd J. Flinn. Self-tuning Wireless Network Power Mngement. In Proceedings of the Annul ACM/IEEE Interntionl Conference on Mobile Computing (MobiCom), pges , New York, NY, USA, ACM Press. [3] Asterisk. The Open Source PBX. [4] P. Bhl, A. Ady, J. Pdhye, nd A. Wolmn. Reconsidering Wireless Systems with Multiple Rdios. ACM Computer Communiction Review, Jul [5] D. Bertozzi, A. Rghunthn, L. Benini, nd S. Rvi. Trnsport Protocol Optimiztion for Energy Efficient Wireless Embedded Systems. In Proceedings of the conference on Design, Automtion nd Test in Europe (DATE 03), pge 10706, Wshington, DC, USA, IEEE Computer Society. [6] R. Chndr, V. Pdmnbhn, nd M. Zhng. WiFiProfiler: Coopertive Fult Dignosis in WLANs. In Proceedings of the Annul ACM/USENIX Interntionl Conference on Mobile Systems, Applictions nd Services (MobiSys), [7] COUNTERPATH. X-Lite 3.0 telephony client. [8] J. Flinn nd M. Stynrynn. Mnging Bttery Lifetime with Energy-Awre Adpttion. ACM Trnsctions on Computer Systems, 22(2): , [9] FMA. float s Mobile Agent Online. [10] GSM World. TW 09 Bttery Life Mesurement Technique. [11] N. Hller. The S/KEY One-Time Pssword System. RFC 1760, Februry [12] IEEE802.11b/D3.0. Wireless LAN Medium Access Control(MAC) nd Physicl (PHY) Lyer Specifiction: High Speed Physicl Lyer Extensions in the 2.4 GHz Bnd, [13] Junction Networks. SIP, IAX, IAX2 nd Asterisk VoIP Service for Business. [14] Kineto Wireless. The UMA Compny. [15] R. Krshinsky nd H. Blkrishnn. Minimizing Energy for Wireless Web Access with Bounded Slowdown. In Proceedings of the Annul ACM/IEEE Interntionl Conference on Mobile Computing (MobiCom), pges , New York, NY, USA, ACM Press. [16] R. Krvets nd P. Krishnn. Appliction-driven Power Mngement for Mobile Communiction. Wireless Networks, 6(4): , [17] L. Lmport. Pssword Authentiction with Insecure Communiction. Communictions of the ACM, November [18] K. Mhmud, M. Inoue, H. Murkmi, nd M. Hsegw. Energy Consumption Mesurement of Wireless Interfces in Multi-Service User Terminls for Heterogeneous Networks. In ICICE Trnsctions on Communictions, [19] G. Prsons. Rel-time Fcsimile (T.38) - imge/t38 MIME Sub-type Registrtion. RFC 3362, August [20] T. Pering, Y. Agrwl, R. Gupt, nd R. Wnt. CoolSpots: Reducing the Power Consumption of Wireless Mobile Devices with Multiple Rdio Interfces. In Proceedings of the Annul ACM/USENIX Interntionl Conference on Mobile Systems, Applictions nd Services (MobiSys), [21] J. Rosenberg, H. Schulzrinne, G. Cmrillo, A. Johnston, J. Peterson, R. Sprks, M. Hndley, nd E. Schooler. SIP: Session Initition Protocol. RFC 3261, June [22] H. Schulzrinne nd J. Rosenberg. A Comprison of SIP nd H.323 for Internet Telephony. Proceedings of Network nd Operting System Support for Digitl Audio nd Video (NOSSDAV), [23] E. Shih, P. Bhl, nd M. J. Sinclir. Wke on Wireless: An Event Driven Energy Sving Strtegy for Bttery Operted Devices. In Proceedings of the Annul ACM/IEEE Interntionl Conference on Mobile Computing (MobiCom), [24] Sipur. SPA-3000 Anlog Telephony Adpter. [25] J. Sorber, N. Bnerjee, M. D. Corner, nd S. Rollins. Turducken: Hierrchicl Power Mngement for Mobile Devices. In Proceedings of the Annul ACM/USENIX Interntionl Conference on Mobile Systems, Applictions nd Services (MobiSys), [26] SpoofCrd. Be Who You Wnt To Be. [27] Spooftel. The Worlds Leder In Cller ID Spoofing. [28] T-Mobile. Stick Together with T-Mobile. [29] The New York Times. T-Mobile Tests Dul Wi-Fi nd Cell Service, October [30] Thoms J. Nvin, Chief, Wireline Competition Bureu, FCC. H.R. 5126, the Truth in Cller ID Act of 2006, My [31] voip-info.org. The VoIP Wiki. [32] H. Woesner, J.-P. Ebert, M. Schlger, nd A. Wolisz. Power Sving Mechnisms in Emerging Stndrds for Wireless LANs: The MAC Level Perspective. IEEE Personl Communictions, 5(3):40 48, June