universal inbox: providing extensible personal mobility
TRANSCRIPT
Universal Inbox: Providing ExtensiblePersonalMobility and Service Mobility inan Integrated Communication Network
BhaskaranRaman RandyH. Katz Anthony D. JosephCSDivision,EECSDepartment,U.C.Berkeley, CA 94720,USA�
bhaskar,randy,adj� @cs.berkeley.eduPhone:+1-510-642-8284,Fax: +1-510-642-5775
Abstract
Communication technology has been seeing rapidgrowth,characterizedby new accessnetworks(e.g., cellu-lar, pager, wireless-IP)and end-devices(e.g., PDAs, two-waypagers, multi-modelaccessdevices).There havebeenseveral efforts at integrating servicesacrosssuch hetero-geneity. However, little work hasbeendoneon identifyinganunderlyingarchitecturefor such anintegration.Weiden-tify therequirementsfor this in thecontext of an integratednetworkwith heterogeneousend-points.TheUniversal In-box provides(a) genericdatatypetransformation,(b) cus-tomizableredirectionof incomingcommunicationbasedonuserpreferenceprofiles,and(c) devicenamemappingandtranslation.Wepresentanarchitecturemappingthesefunc-tionalitiesto reusableinfrastructurecomponentsrealizedasInternetservices.Theuniquefeature of thearchitecture isits extensibility – it allows not only the integration of ex-isting end-points,but also extensionin termsof the end-devicesandnovelservicesit canhandle.
We haveimplementedthe Universal Inbox componentsin a test-bedsetting, supportinga variety of devicesandservices:GSM cellular-phones,voice-over-IP end-points,voice-mail,e-mail,instantmessagingservice, etc.With ourarchitecture, building personalmobility andservicemobil-ity features,andextendingthemto new end-pointshasbeeneasyin conceptand in implementation.Theperformanceanalyseswith theinitial implementationshowthat eventheheavy-weightcomponentscanbescaledto accommodatealargeuser-base.
1. Intr oduction and Moti vation
Theconceptof PersonalCommunicationServices(PCS)comesfrom the telecommunicationsdomain [9, 26, 31].While anoften looselyusedterm,PCS,in its mostgeneralsenserefersto theprovisionof personalizedvoiceanddata
servicesindependentof thenetwork [4]. It identifiesthreekindsof mobility: (a)personalmobility – theability to redi-rectcommunicationacrossheterogeneoususerdevices,(b)servicemobility – this providesaccessto servicesindepen-dentof theuser’s end-point;i.e., theuserseesthesamesetof servicesfrom all end-points,and(c) terminalmobility –allowing usersto move from onephysicallocation to an-otherwhile having thesamesetof servicesavailable. Ter-minal mobility is providedby today’scellularnetworks. Inthis paper, we concernourselveswith the other two: per-sonalmobilityandservicemobility. In therestof thepaper,theterm“mobility” refersto thesetwo kindsof mobility.
With new communicationdevices and servicesemerg-ing at a rapid pace,today’s userhasa rangeof communi-cationend-points. Considerthe scenariodepictedin Fig-ure1. A userhasseveraldevices(cell-phone,pager, PSTNphone,desktopat office, etc.) andservices(e-mail, voice-mail, instantmessaging,informationaccessservices).Shemaywish to manageincomingcommunicationin a flexiblemanner. The figure shows redirectionto different deviceend-pointsbasedonwhois calling,thetime-of-the-day, im-portancelevel, etc. Furthermore,the usermaywish to ac-cessdifferentservices:news headlineservice,personalin-formationlikecalendarservice,here-mailfolders,etc.Sheshouldbe ableto do this independentof the accessdevicesheis using.
The first aspect(flexible redirection)in the above sce-narioconstitutespersonalmobility. Thesecond(serviceac-cess)representsservicemobility. Therehasbeena lot ofinterestandpreviouswork onthefunctionalaspectsof suchfeatures(e.g.,[22, 28, 1]). Therearealsoseveralcommer-cial servicesthatprovidesomeof theintegrationfunctional-ity (e.g.,[14, 10, 12, 15, 17]). However, therehasbeenlittleresearchinto the infrastructuresupportrequiredto supportthesemobility featuresin an extensibleandscalablefash-ion. Therearethreemaingoalsin this work:
1. Extensibility: With the paceat which technologyismoving in this domain,it makeslittle senseto provide
Calls frompersonal friends
Calls duringoffice-time
ImportantE-mail headers
Calls inthe evening
Anonymous callers
Cell-Phone
Office-Desktop
Voice-Mail
Device end-pointsService end-points
Pager
Home-Phone
Figure 1. A scenario sho wing personaliz ed,integrated comm unication
amechanismthatonly accommodatesexistingdevicesor services.Thus,ourprimarygoalin thedesignof theUniversalInbox is extensibility. It shouldbe easytoaddemerging communicationservices,and integratethemwith all of the existing ones. The right compo-nentfunctionalitiesshouldbeprovidedsothatthispro-cessof integrationinvolvesminimaldevelopment,andminimaldeployment.
2. Scalability: This is animportantconcern– thesystemmust scaleto accommodatea large usercommunity,and must be capableof operationon a global scale.This is our secondimportantgoal.
3. Personalization:Integrationis of little usewithoutper-sonalization. Specifically, we meanthat usershouldbe ableto specifypreferencesfor ubiquitousredirec-tion of incomingcommunication(suchasthosein Fig-ure1). This is our third goal.
TheUniversal Inbox is our realizationof anintegrationarchitecturewith all thesefeatures.It signifiesthe mecha-nismfor achieving flexible personalmobility acrosshetero-geneouscommunicationservices.Theuserseesa unified,conceptualinbox of incomingcommunicationreceivedviadifferent channels. We presenta genericarchitectureforproviding any-to-anyintegrationof existing aswell as fu-turedevices. Thearchitecturealsosupportsservicemobil-ity acrosstheuser’s setof devices.
Thechallengein thedesignof theUniversalInbox is incomingup with the right separationof functionalcompo-
nents;onethatenablesa scalablearchitecturethatcaneas-ily be extendedto newly emerging devices. The compo-nentsshouldbe independentof oneanotherin designanddeployment,while still beinginter-operable.
For therealizationof thefeaturesetexemplifiedby Fig-ure1, we identify threekey functionalcapabilities:(a)any-to-any datatransformation– for accommodatingdiversede-viceswith differentdataformats,(b) storageandprocessingof userpreferences– for ubiquitousredirectionof incomingcommunication,and(c) device nametranslationandmap-ping – to handlethe heterogeneousnamespaceslike cell-phonenumbers,pagernumbers,IP-addresses,etc. Impor-tantly, wepresentanarchitecturemappingthesecapabilitiesto independentinfrastructureservices.
To gain insight into the requirementsfor building per-sonalmobility services,we have implementedthe compo-nentsof our designin a test-bedsettingthat includesGSMcell-phones,desktopIP end-points,regular e-mail, instantmessagingservice,etc. The (re)useof the threefunctionalbuilding blocksmadetheadditionof eachsubsequentend-point easier. In this paper, we presentthe designof oursystemandtheexperiencegainedfrom theimplementation.To addressprovisioningandscalingconcernsof theinfras-tructureservices,we have donepreliminary performancetestswith our implementation.Theseshow that even theheavy-weightdatatransformationcomponentcanbescaledto a large-userbase. This supportsour architecturaldeci-sionto placethecomponentsin theinfrastructureassharedservices.
The restof the paperis organizedasfollows. The nextSectionpresentsthe principlesunderlyingour designfol-lowedby theactualdesignof thearchitecturalcomponents.Section3 illustratesthe extensibility aspectsof our designby meansof a discussionof exampleservicesthatwe havebuilt. Section4 presentstheresultsof theperformancetestsfor scaling.Section5 discussesrelatedwork andSection6summarizesour conclusions.
2. Designof the Ar chitecture
Thefollowingprinciplesarekey to thedesignof theUni-versalInbox.
1. Separation of Functionality: The first principle thatwe follow is to clearlyseparatefunctionalcapabilitiesso that they canbe implementedanddeployed as in-dependent,reusablenetwork components.The reuseof functionalityimprovesextensibility. Further, sharednetwork servicescanbescaledwell usingclustercom-putingplatforms[6].
2. Providenetworkanddeviceindependence:By provid-ing these,it becomeseasyto implementuniformfunc-tionality that spansheterogeneoususerdevices. For
instance,supposethatwe have the functionality of e-mail accessthroughcell-phone.With network andde-vice independencetaken careof by the components,the samefunctionality would be readily availableontheuser’sPSTNphoneaswell.
3. Pushcontrol towardscallee: In thecurrentcommuni-cationparadigm,the caller controlshow to reachthecallee.This is at loggerheadswith theconceptof per-sonalmobility andpersonalization.Flexible handlingof incoming communicationis achieved by pushingcontrolaway from thecallerto thecallee.
2.1. Componentsof the Ar chitecture
For integration of heterogeneousdevices and services,werequire(at least)thefollowing functionalcapabilities.
� Any-to-any datatransformation:this would bean im-portantpiecethat provides device independence.Inpart,by handlingdatatypetransformationin agenericfashion,it would provide device data type indepen-dence.
� User preferencebasedubiquitous redirection: thisfunctionality would enablepersonalizedredirectionof incoming communicationbetweendifferent end-pointsof thecallee.
� Device or serviceend-pointnamemappingandtrans-lation: therequirementfor this capabilitycanbeseendirectly from Figure1. If the userhasdifferentend-devices or serviceswith different names,mappingbetweentheir identities is necessaryfor integration.This functionality would provide device nameinde-pendence.
Apart from thesecomponents,we have gateways orAccess-Points(APs) bridging differentaccessnetworks tothe Internet(Figure2). They performthe importantfunc-tion of protocol translation(proxying) betweenthe accessnetwork protocol and an Internet sessionprotocol (likeSIP[30]). They establishandtear-down sessionsassociatedwith user-to-usercommunicationor serviceaccess.APsusethedata-transformationandname-mappingcomponentsfordevice-independentoperation.
We have madethe crucial designchoice to have ourarchitecturebe network- rather than edge-centered.Thatis, we implementthe mobility componentsas servicesinthecoreinfrastructure,asopposedto colocatingthemwiththe access-pointsat the edges.This is shown in Figure2.Theaccess-pointsusethecorecomponentsfor themobilityfunctionalities.(By coreinfrastructure,we meantheInter-netthatis in themiddleof all thedifferentaccessnetworks
Name mapping servers
Preference based redirection agents: Preference Registry
Data Transformation Agents: APC-Service
Access Point 1
Access Point 2
Access Point 3
Access Point 4
Service 1 (E-mail)
Service 2 (Instant Messaging)
Device end-point 1 (Cellular Phones)
Internet-Core
Device end-point 2 (Voice-over-IP)
Figure 2. Reusab le components in theInternet-core
– thisdoesnotnecessarilymeanthecore“backbone”of theInternet).
This is a crucial deviation from the approachtakenby otherarchitectureslike the Mobile PeopleArchitecture(MPA) [28] in which the mobility componentsare colo-catedwith thegateway functionalityat theedgeof two net-works. It is alsodifferent from today’s integrationof theGSMcellularnetwork with thePSTN– this is donethroughanInter-WorkingFunction(IWF) at theedgeof thetwo net-works[24].
This design choice is in accordancewith our goals.Placementof functionalityin thecoresimplifiesextensibil-ity: reuseof thesecomponentssimplifiesdevelopmentanddeploymentof new accesspoints. Componentsin thecorecanbesharedby multipleaccess-points.They canbeincre-mentallyprovisionedto accommodateagrowing usercom-munity. And their implementationcanalso leveragescal-ableclusterserviceplatforms[6, 8].
In thefollowingsubsections,wediscussthearchitecturalcomponentsin turn.
2.2. Data Transformation Service: Automatic PathCreation
In mobility scenariosinvolving heterogenousdevicesorservices,someform of datatransformationis required. Inaccordancewith our designprinciple(#1),we separatethis
functionality into an independentcomponentthat can bereusedby all mobility features.This componentis thedatatransformationservice.
The datatransformationcomponentleveragesthe pow-erful conceptof AutomaticPath Creation(APC) from theNinja project [11]. In APC, an operator is a genericdatatransformer(e.g.,anaudiocodec),anda path is a seriesofoperatorsstrungtogether[20]. This is depictedin Figure3.Thepathshown consistsof two operators(thebold lines)–it convertsa givenpieceof text to PCMaudio.
Speech synthesizer PCM encoder
GSM encoderHTML text extractor
HTML-Email
Plain text PCM audio
GSM encoded audio
Figure 3. Illustration of a Path
SincethiscomponentusesAPC,wealsocall it theAPC-Service. Theterm“automatic”refersto thefactthatweonlyneedto specifytheinputandoutputdataformats(andinputsourceandoutputsink) to theAPC-Service,it thenstringstogethertheoperatorsnecessaryfor thetransformation“au-tomatically”.
Thisprovidesahighly extensiblemodel.For instance,inFigure3, supposeonewishesto addsupportfor GSMaudioaswell, all thatneedsto bedoneis to addanoperator(seethe dottedlines on the right). Similarly, supposewe wantto addsupportfor conversionof HTML e-mail messages,we would just have to addtheappropriateoperator(seethedottedlineson theleft).
A genericdata transformationcomponentis absentintoday’s communicationinfrastructure.Transformations,ifany, happenat the edges(e.g.,at the Inter-Working Func-tion betweentheGSM andPSTNnetworks[24], or at eachserviceproviderdeploying integrationservices)andarenotgenericenoughor reusablefor otherservices.
2.3. PreferenceRegistry for Redirection
The secondfunctionality commonto personalmobilityscenariosis redirection. Redirectionis often highly user-specific (refer to Figure 1). This functionality is imple-mentedwithin the PreferenceRegistry (PR) component.The PR storesand processesuserpreferenceprofiles andactsastheredirectionagentacrossheterogenousdevices.Itrealizesthe“control for thecallee”designprinciple(#3).
User’s preferencespecifiesthe way a particularincom-ing communicationshouldbe handled. It is a function ofseveral factorslike the time of the day, caller-id, userlo-cation,userstate,andso on. The inputscanbe classifiedinto per-sessioninputs(thefirst two in thepreviouslist) and
dynamicinputs(the last two). The output is the preferredend-pointof thecallee.
We representuserpreferenceasasetof rules.Wemodelit asa script that is processedby the PR,eachtime with anew setof input valuesto the script. ProjectssuchastheMPA [28], TOPS[1], andActiveMessenger[22] haveusedsimilarwaysof representinguserprofilesandcollectingtheinput parameters.We view theseascomplementaryto thisaspectof our system.Figure4 shows anexampleof a userpreferencescript.
IF (9AM $<$ hour $<$ 5PM) // At OfficeTHEN Preferred-End-Point = Office-Phone;
IF (5PM $<$ hour $<$ 11PM) // At HomeTHEN Preferred-End-Point = Home-Phone;
IF (11PM $<$ hour $<$ 9AM) // SleepingTHEN Preferred-End-Point = Voice-Mail;
Figure 4. A Simple Preference Script
Figure 5. A screen-shot of the GUI for speci-fying user pref erences
TheUserInterfaceissueis an orthogonal,albeit impor-tantone. Building an interfaceto let theuserspecifypref-erencesbasedon simple parameterslike time-of-day, andcaller-id is straightforward. It is morecomplicatedto spec-ify rulessuchas: forward faxescominginto my office ase-mail, if I have not beenin the office for 2 days. Wehave built a GUI for specifyingsimple preferencescripts– a screen-shotof this is shown in Figure5. We arein theprocessof perfectingthis GUI to performusagestudiesinthefuture.
Justaswith formattranslation,redirectionisdonemostlyat the edgestoday: theuserspecifiesthe numberto whichincoming calls to a particular end-point should be for-
warded. While this is a useful functionality supportedbysessionsetupprotocolslike SIP[30], redirectionacrossde-vicesfor personalmobility shouldreally be doneat a cen-tral point. Placingthis functionalityat theedgesmeansthatit hasto be replicatedeachtime thereis a new end-point(i.e., theuserhasto specifyredirectionfor eachof theend-points).Centralizingredirectionin thePreferenceRegistryis in accordancewith our goalsof extensibility to new end-points.
2.4. Naming service
The Naming serviceis a componentrequiredfor han-dling heterogeneousdevicesandservicesthat have differ-entnamespaces.It allows usto mapbetweenthedifferentuserend-pointidentitiesin thesenamespaces.We defineaunique-idfor auserwhichis equivalentto MPA’sPoID[28]or UMTS’sUPT number[26].
The Namingservicemapsbetweenthe identitiesof theuser’s different end-devices, or communicationservices.All these identities map to her unique-id – this allowslookupof furtherinformationindexedon theuser’sunique-id. For instance,the locationof the user’s preferencereg-istry is determinedasa mappingfrom theunique-id.
TheNamingserviceis usedasthebootstrapmechanismfor locatinga useror a serviceend-point. Henceit needsto be globally distributed and scalable. We considertwooptionsto achieve this. The Domain NameSystem[23]is a globally distributedmappingservicein usein the In-ternettoday. Onepossibilityis to usetheDNSfor themap-pingswewant.Namespaceslikecell-phonenumberscouldbeconvertedto thedottedstringnotationfor makingthemDNS entries. And a specialtype of DNS recordcould beusedfor theentrieswe areinterestedin.
A secondpossibilityis to useahierarchicaltreeseparatefrom DNS,but usesimilarmechanismsfor distributionsandscaling.Thefirst choicehastheadvantageof usingtheex-isting DNS infrastructure;but might endup overloadingit.Thesecondchoiceallows theflexibility of having separatecachingandownershipsemantics.This is importantsincethe useof our namingentriesis likely to be very differentfrom today’s DNS. We are continuingto explore the twochoices,but have taken the secondapproachsinceit waseasyfor implementationin our testbed.
In eithercase,extendingthenamehierarchyis easy. Ad-dition of a new name-spaceinvolvestheadditionof a sub-tree to the namehierarchy. Figure 6 shows an examplewherethe namehierarchyhasbeenextendedto includeanew pagingservicethathasa new namespacefor its pagerend-pointidentities.
IP-Addresses Cell-phone numbers
PSTN phone numbers
Pager numbers
Name-space Hierarchy
Figure 6. Extending the name-space: an ex-ample
2.5. AccessPoints
An AccessPoint (AP)providesgatewayfunctionalityforanaccessnetwork. It exportsa genericsessionsetupinter-faceto the Internetcore. Thecommonsessionsetupinter-faceprovidesa level of indirectionthat is key to achievingnetwork independence(designprinciple#2).
An AP could interfaceto a serviceor to devices in anaccessnetwork. For instance,we could have an AP tointerfacewith an e-mail store,and anotherat the MobileSwitchingCenter(MSC) [27] of a GSM network to inter-facewith cellular-phones.An AP actsasa client whenitestablishesoutgoing(i.e., into the Internetcore) sessions,andasa serverwhenit acceptsincomingsessions.
2.6. Putting it all together: An Example
Figure7 showsasimplepersonalmobility scenariousingthe architecturalcomponentsintroducedabove. It showshow personalizedredirectionwould work acrossheteroge-neousdevice-types.Thecallerdialsa numberfrom thecel-lular network. TheAP at theedge(e.g.,at theMSC or theBase-Station)interceptsthis (step1) andgetsthe unique-id andthe locationof the preferenceregistry of the calleeusingthe distributedNamingservice(step2). It thengetsthe currentpreferredend-pointof the calleefrom his PR(step3) andestablishesa call sessionthroughanotherAPto the callee(steps4-7). An APC serviceinstancein theinfrastructureis usedfor any datatransformation(step8).(Weview theproblemof locatinganappropriateservicein-stanceasanimportantbut orthogonalproblem).
3. Extensibility in the Universal Inbox
In thissection,wepresenttheextensibilityfeaturesof theUniversalInboxby describingourexperiencewith buildingmobility featuresin the framework presentedabove. It isimportantto notethat the individual functionalitieswe de-scribeherearenot novel by themselves. But theway theyare built by (re)usingthe separatecomponentsis what isunique. In Section3.1, we list the functionalitieswe have
Bob’sPreferenceRegistry
NetworkGSM
1
2
34
Naming Service
PSTNNetwork
5
6
Telephone (Bob)Cell-Phone (Alice)
97
Internet Core
APC Service
8
AP2AP1
Figure 7. Putting it all tog ether: An Example
implementedincrementallyand describethe different ex-tensionswe have madeto the Universal Inbox. Then inSection3.2we discusstheseextensibility featuresandalsosomeof thecaveats.
3.1. Implementation Experience
Figure8 andTable1 show thestep-wiseadditionof end-points and featuresto the Universal-Inbox. Specifically,they show theAccess-Points,andoperatorsat theAPC ser-vice that wereadded.During eachstep,additionalprefer-enceprofilesandnamingentrieswerealsocreated.How-ever, theseare not shown sincetheseare only configura-tion changesandnot functionalityadditions.The“+” at thebeginning of eachentry in Table 1 denotesthat the entryrepresentsan addition to the set of end-points,operators,andfeatures.(All of theAPsin thetablehave beenimple-mented,exceptthePSTNAP – row #7).
To startwith (row #1 of Table1), we have two kindsofend-pointsin implementation:(a) GSM cell-phones,and(b) Desktopvoice-over-IP end-pointsin theform of theVi-sual Audio Tool (VAT) [19]. Each kind of end-point isreachablethroughanAccessPoint.TheGSMAPinterfacedto thecell-phonesthrougha Base-Stationanda BSC/MSCsimulator;thedetailsof the interfacearenot relevanthere.TheVAT end-pointsusetheGSMcodecandwehaveasin-gledatatypein oursystem:GSMaudio.
Thenamehierarchyhasentriesfor IP-addressesandcell-phonenumbers. Personalizedredirectionacrossthe het-erogeneousend-pointsis possiblethrough the useof thePRandNamingservicecomponents.Theexamplein Sec-tion 2.6showedhow this wouldwork.
Extension of the redirection functionality to includevoice-mailinvolvestheadditionof anappropriateAP (row#2). This AP also allows a userto accessher voice-mailthrougheitherof the earlier two end-points.Note that thedevelopmentanddeploymentof thisvoice-mailAP is inde-pendentof thepreviouslyexistingAPs.
Thefirst text-basedend-pointweintegrateis e-mail(row
#3). For this, we implementa client AccessPoint thatresidesat the user’s e-mail storeandestablishesoutgoingsessionsfor readingout e-mail to theuser’s preferredend-point. For eache-mailreceivedin theuser’s inbox, theAc-cessPoint checksthe user’s PreferenceRegistry to seeif(a copy of) thee-mail shouldberedirectedto anotherend-point (e.g.,theuser’scell-phone).
Thesupportrequiredfor thisat theAPCServiceis threeoperatorsfor text to speechconversion:(a)text to sun-audio(basedon festival [5]), (b) sun-audioto PCM(basedon thesox Unix program),and (c) PCM to GSM (basedon thetoast GSM codec[3]). With this in place,e-mailscannowberedirectedto all previousend-points.
Next, wedoasimilar integrationwith aninstantmessag-ing service,by implementinganAP for thesame(row #4).The AP interfacedwith the Sanctioinstantmessagingser-vicethatwasdevelopedaspartof theNinja project[11]. Wecannow reuseall of theAPCfunctionalityaddedin thepre-viousstep.Thefunctionalitiesavailablewith e-mailearlierarenow readilyavailablewith instantmessagingaswell.
We now enableaccessto two servicesin turn. Thefirstis theJukeboxservice(row #5)– whichwasalsodevelopedindependentlyaspartof theNinja project[11]; theserviceplaysstreamingMPEG3encodedmusicto theuser’s desk-top. We addan AP to proxy for this service,andalsoaddanoperatorat theAPCservice(MPEG3to PCMconverter,basedon the mpg123 unix program). We reusethe PCMto GSM operatoraddedearlier, andaccessto this serviceisnow enabledfrom the device end-points:cell-phonesandVoIPdesktops.
The secondservicewe enableaccessto is the Media-Managerservice(row #6). This wasalsodevelopedinde-pendentlyasa separateproject. It is a servicethat sits infront of theuser’s e-mail store,andis capableof doing in-telligent processing(suchassummarizing)on the e-mail.Enablingaccessto this involved building the AP to proxyfor it. TheMediaManageris capableof outputtingseveralaudioformatsincluding the GSM format. Henceno addi-tionaloperatorsarerequiredat theAPCservice.
Finally, we considerhow we canaddPSTN telephoneend-pointsto the system(row #7). This capabilityhasnotbeenfully implementedyet. WehaveaH.323gateway[13]interfacing with the PSTN network. We needto add anAP in front of this gateway. This gateway supportsonlythe G.723audioformat. To interoperatewith GSM-basedend-points,weneedto addthethreeoperatorsshown in thetable. With this done,all of the previous functionalities:redirection,screening,andserviceaccessthat werepossi-ble with the earlierend-points,will now be possiblewithPSTNtelephonesaswell.
Op1 -- text to sun-audioOp2 -- sun-audio to PCMOp3 -- PCM to GSMOp4 -- MPEG3 to PCMOp5 -- G.723 to PCMOp6 -- PCM to G.723Op7 -- GSM to PCM
Internet-Core
Preference Registry
Naming Service
Automatic Path Creation ServiceCell-phone AP
PSTN AP
MediaManager AP
Instant-messaging-client AP
Mail-push-client APVoice-mail AP
VAT AP
Email Store
Jukebox service
Email Store
MediaManager Service
H.323 Gateway
Instant messaging
Desktop runningVAT
Voice-mail Store
service
Jukebox AP
GSM cellular-phone
1
2
34
5
6
7
8
Figure 8. Step-wise additions to the Univer sal-Inbo x (refer Table 1)
3.2. Discussionof Extensibility Features
In general,extendingthe systemto new devicesor ser-vicesinvolvestheadditionof anAccessPoint. An AccessPointessentiallyprovidesthe glue for integration. It hasadevice- or service-specificpart, and it hasa genericpart.The genericpart is the Internetsessionestablishmentpro-tocol, suchasSIP [30]. In implementation,we have useda simpleJava RMI basedsessioninitiation andterminationprotocol,sincethis is not thefocusof ourwork.
Thedevice- or service-specificpartof theAP couldbequite complicated. For instance,developing this for theGSM AP requiredunderstandingthe GSM protocol stackandwasa considerableeffort of aboutnineperson-months.However, APs to simpleservicescanbe developedeasily.The interfacesto the Jukeboxserviceand the MediaMan-agerserviceare quite simple – JavaRMI calls to retrievesongsandmessagesrespectively. APsto theseservicesareonly about700linesof Javacodeeach– onecouldconsideraddingmorefrills to theseAPsthough.
While extendingthe system,in somecases,whentherearenew dataformatsinvolved,operatorshaveto beaddedtoanAPC serviceinstance.Hereagain,anoperatormaynotbeeasyto implementby any means.For example,a text tospeechconversionsoftwareis non-trivial. But thekey is thatsuchfunctionalitiescanbereused– not only in implemen-tation, but alsoin deployment. That is, a third party APCservicein the Internet-corecanbeusedfor theappropriateconversions.This is richer thanthe reuseof functionality
that is possiblewith otherarchitectureslike theMPA [28].An MPA Personal-Proxy(PP) can reusethe “conversiondrivers” for differentmobility features. But suchreuseisnot possibleacrosstwo instancesof thePP.
Thedeploymentof new servicesandintegrationof newdevicesis helpedby thefactthattheaccesspointsareinde-pendent. They canbe developedanddeployedat differentpointsin theinfrastructure,by differentparties.
Theextensibility featuresof ourarchitectureareenabledby the separationandreuseof components.While this isa rich feature,therecouldbe drawbacksin somecases.Ifthe interfacesbetweenthe componentsaredefinedover anetwork, they cannotbe asrich asthey canbe whencom-ponentsaretightly coupled.Considerfor example,thecaseof theMPA wherethePersonalProxyencapsulatesboththePreferenceRegistry functionalityaswell asAPC function-ality. It canimplementserviceslike “if the e-mail hasthewords freecoffee, andI’m at my office, beepmy pagersothat I don’t missout”. This taskwould involve closeinter-actionbetweenthedatatransformationcomponentandtheuserpreferenceprocessingcomponentandcannotbedoneeasily in our casewherethe two could be separatedovera network. Thusthe extensibility andreusegainedby theseparationmeansthelossof someflexibility .
Separationof componentscouldalsomeanadditionalla-tency. In Figure7, theNamingservice,PR,andAPC haveto be accessedseparately. This couldaddto the call setuplatency. However, this canbe addressedby placing thesecomponentsso that they are not far apart in the network.
Device/ServiceAP Operatorsin APC Personal/Servicemobility features
1 Cell-phones(#1)& (none) Call redirection/screeningbasedon time-of-day& caller-idVoice-over-IP (#2)
2 (+) Voice-mail(#3) (none) Call redirectionto voice-mailalsopossibleVoice-mailaccessfrom cell-phone/VoIP end-points
3 (+) Mail-push-client(#4) Op1(text to sun-audio) Email redirectionto cell-phone/VoIP/Voice-mailOp2(sun-audioto PCM)Op3(PCM to GSM)
4 (+) Instant-message-client(#5) (none) Instantmessageredirectionto cell-phone/VoIP/Voice-mail5 (+) Jukebox-service(#6) Op4(MPEG3to PCM) Jukeboxaccessfrom cell-phone/VoIP6 (+) MediaManager-service(#7) (none) MediaManageraccessfrom cell-phone/VoIP7 (+) PSTNend-points(#8) Op5(G.723to PCM) Call redirectionto PSTN,E-mail redirectionto PSTN
Op6(PCM to G.723) Instant-messageredirectionto PSTNOp7(GSM to PCM) Jukebox& MediaManageraccessfrom PSTN
Table 1. Step-wise additions to the Univer sal-Inbo x (refer Figure 8)
For instance,if a telephoneserviceproviderdeploys anac-cesspointataswitch,theserviceprovidercouldalsodeploy(or use)anAPCserviceneartheAP to reducethecall setuplatency.
4. Scalability Analysis
In ourdesign,thethreearchitecturalcomponentsareim-plementedanddeployed assharedinfrastructureservices.Therearescalingandprovisioningconcernsthathaveto beaddressedfor suchsharedservices. This sectionpresentstheresultsof stress-testingour implementationfor scalabil-ity. Thenumbersin thissectiongiveanideaof thecomputeresourcesrequiredto supporta givensizeuser-community.We alsoprovide latency measurements;however, they donot includewide-areanetwork latencies,sinceour currenttestbeddoesnot spanthewide-area.
Among the three components,the naming service islight-weightby nature,sinceit only involvesname-lookups,andcanbenefitfrom optimizationslike caching.Hencewefocuson theperformanceof theothertwo components.Wenow briefly describethe main featuresof our implementa-tion beforepresentingtheresultsof theperformanceexper-iments.
4.1. Relevant Implementation Details
The APC Serviceand the PreferenceRegistry compo-nentsareJava-basedimplementations.In accordancewithour goalsof scalability, theAPC Serviceis structuredfor acluster-basedimplementation.It hasafront-endandseveralback-ends;eachback-endis capableof runningoperators.The front-enddecideswhich operatorsto run and where.The operatorsthemselvesareall in C, sincethey performthebulk of transformations,andhave Java wrappersat theback-endnodes.
ThePRalsohasa front-endanda back-end.Theback-endimplementsthe storageof the userpreferencescripts,andthefront-endprocessesthem.Theback-endusesa dis-tributed, persistent,cluster-basedstoragemechanism[7].The scriptsarerepresentedin TCL andthe front-endusesaJaclinterpreterto processthem[16].
For all the tests,we used500Mhz Pentium-III 2-waymultiprocessormachinesfor theservers(i.e., thefunctionalcomponents)and a 400MHz Pentium-II machinefor theclient. Theservershad256MBof mainmemoryand512KBof processor-cachein eachof the processors.The serverswerein acluster, andtheclientwasseparatedfrom themby6 hopswithin anin-building LAN (approx.1msround-triptime). All machineswererunningLinux-2.2. All the JavaprogramsusedIBM’ sJDK v1.1.8.
4.2. The APC Service
At the time of this writing, the APC servicehasgonethroughoneroundof performanceoptimization.Our orig-inal implementationmodeledoperatorsasunix processes;one suchprocesswould run for eachpath in a back-endnode.This did not scalewell dueto theoverheadof a pro-cessperoperatorperpath.
In the next roundof implementation,we have modeledoperatorsasbeingsharableby multiple paths.A singleop-eratorhandlesmultiple pathsby readingfrom andwritingto differentsockets. We show the performanceof this op-timized implementationbelow. We have implementedthetoast (PCM-to-GSM)anduntoast (GSM-to-PCM)opera-tors underthis optimizedmodel. We have not yet imple-mentedtheotheroperatorsin this model. For comparison,we alsoimplementeda null operatorthatsimply copiesitsinput to output(weusePCMdataratefor this operator).
A pathpersistsfor the durationof a session.Sessionsmay last for varying periodsof time. One can expect a
0
5
10
15
20
0 10 20 30 40 50 60 70 80 90 100
Thr
ough
put (
Num
ber
of p
ath
crea
tions
per
sec
ond)
Number of Simultaneous Paths
Original null opOptimized null op
PCM to GSM (Toast)GSM to PCM (Untoast)
Figure 9. Path creation thr oughput
0
20
40
60
80
100
120
140
0 10 20 30 40 50 60 70 80 90 100
Pat
h C
reat
ion
Late
ncy
(ms)
Number of Simultaneous Paths
Original null opOptimized null op
PCM to GSM (Toast)GSM to PCM (Untoast)
Figure 10. Path creation latenc y
certainnumberof pathsin serviceat any giventime. Thisnumberaveragedover time is a measureof the loadat theAPC service.For measurementcontrol,we fix this metricof load for thedurationof an experiment(i.e., we createafixed numberof pathsat the beginning) andvary it acrossdifferentruns.With this fixedloadat theserver, a client re-peatedlycreatesandtears-down furtherpaths.All thepre-existing pathshaddatastreamingthroughthem. The datarateis oneaudioframeper20ms;a frameis 160bytesfor8kHzPCMdataand33 bytesfor GSM data.
Underthis setup,we measuretwo parameters:pathcre-ation throughputandlatency. Figures9 and10 show thesetwo parametersasafunctionof theload(i.e., thenumberofsimultaneouspathscreatedat the beginning of the experi-ment). We useseparatefront-endandback-endmachinesfor theseexperiments. The graphsalso show the corre-spondingmeasurementsfor theoptimizedandunoptimizednull operators.
The measurementsshow that an average load of atleast60-70simultaneouscallscanbesupportedbeforethe
throughputdropsto half its valueunderzero-load– for thetoast operator. This numberis evenhigherfor theuntoastoperator. Theunoptimizedoperatorscalesverypoorlysinceit usesa unix processfor eachpath.
Theperformanceof the toast operatorgoesdown morerapidlythanuntoast: GSMencodingis moreheavy-weightthandecoding. The performancefor the (optimized)nulloperatoris actuallyworsethanthatof theuntoast operator.A possiblereasonfor this is that the null operatorusedahigheroutgoingdataratethantheuntoastoperator(thenulloperatorusedPCMdatarateonbothsideswhile theuntoastoperatorusedalowerdatarateGSMaudiofor theincomingdata). This would meanthat the operationsare not CPUintensive, but I/O intensive. We have actually confirmedthisandthenull operatorwith theGSMdataratedoesscalebetter. We hada throughputof 11pathcreationspersecondat a load of 80 simultaneouspaths. We have not includedthis in thegraphfor thesakeof clarity.Calculation of Scaling
Wenow mapthenumberspresentedaboveto thenumberof usersthatcanbesupported.We do this in thecontext oftwo-way telephonecallssincethereareextensive statisticsavailablefor this.
Supposethe averagecall arrival rate is � , andsupposean averagecall lastsfor � , the averagenumberof calls ata given time is ������� at steadystate.The maximumthroughputof the system(rateof pathcreation)shouldbegreaterthanthevalueof � for thesystemto keepfunction-ing steadily.
From the studies in [21], at the busy hour, � ��� �������������������� !���"�$#$ &% (N is thenumberof usersin thesystem)and �'� �� (*)&+-,.� � #�� . FromFigure9, thethrough-put is / 0�213� � �3�����$#�� when �4� (!5
. �6�7� � �8�79 5!5calls/second.Thethroughputis indeedgreaterthanthear-rival rate � .
The number of users is calculated by % �� ��:��; �<�����=�>���!�?���3 �@ �BAC/�D . This meansthat a usercom-munityof over500canbeeasilysupportedby ourtwo-nodeAPC service. This is encouraginggiven that theseoper-atorsare reasonablycomplicated.The telephonenetworkemploys special,expensive hardwareequipmentfor doingthesetransformations(seeTRAU in [25]). We expectevenbetterscalingwith furtheroptimizations.Latency thr ougha path
Finally, we presentthe latency experiencedby a datastreamthrougha path,after pathcreation. Table2 showsthesenumbersfor theoptimizedtoast anduntoast opera-torsandfor theoriginal unoptimizednull operatorfor var-ious path lengths. The numbersin parenthesesgive thestandard-errorfor 200observations;someof thelargevari-ationsarenot surprisinggiven that the round-tripbetweentheclient andtheserver itself was1ms.Evenin thecaseofmultiple operatorpaths,all the operatorswererunningon
thesameback-endmachine.Theselatenciesarequite lowcomparedto typicalnetwork latencies;however, furtherop-timizationsarecertainlypossible.
Operator Latency throughpath
Toastop 9.5ms(0.19ms)Untoastop 11.8ms(0.46ms)
1-null-oppath 3.8ms(0.48ms)2-null-opspath 5.3ms(0.90ms)3-null-opspath 4.5ms(0.09ms)
Table 2. Latenc y thr ough a path
Throughput 55.3requests/sec
Latency breakdownBackendretrieval 8.9ms(0.51ms)
ScriptInterpretation 17.7ms(1.32ms)JavaRMI 9.4ms(2.3ms)
Total 36.0ms(1.79ms)
Table 3. PR thr oughput and latenc y
4.3. The PreferenceRegistry
Wenow presenttheperformancenumbersfor theprefer-enceregistry. In theseexperiments,thePRwaspre-loadedwith preferencescripts(dummy ones)for 5,000differentusers.Eachscriptwas50 linesof TCL. Althoughtheback-endstorecanbedistributedovermultiple nodes,theexper-imentsuseonly a singlenode. This singlenodealsorunsthefront-end.
We hadtwo differentclient threadsto repeatedlyaccessthe preferenceregistry. Table3 shows the throughputandlatency of preferenceregistry access.The tablealsogivesthe breakdown of the latency. The RMI latency wascom-putedby subtractingthe sumof the latenciesat the serverfrom thetotal latency at theclient.Calculation of Scaling
If we consider the call arrival rate of 2.8/hour/user(from [21]), therewould be %E �; ����F;GH( 9C9 call setupspersecondandthecorrespondingsamerateof PRrequestspersecond.Usingthevalueof ACA F lookups/secfrom Table3,weestimatethatasinglePRcansupport%I�J/�D G DK9C9 users.Given that we loadedthe PR with only 5,000userprefer-encescripts,it wouldbesafeto saythatat least5,000userscanbesupportedby asinglemachinePR.
4.4. Additions to SessionSetuplatency
TheNamingService,PRandtheAPC-Servicehaveto beaccessedseparatelyduringsessionsetup(referto Figure7).
FromTable3 andFigure9, we seethat theaccessesto thePRandtheAPC-Serviceaddapproximately36msand50msrespectively to sessionsetup. The NamingServicewouldalsoadd latency, but extensive cachingcanhelp here. AttheAPC-Service,thebreakdown of latency was:5.5msforJavaRMI,19.2msfor communicationbetweenthefront-endandtheback-end(JavaRMI again),and25.4msfor instanti-atingthepathat theback-endnode.Thesenumbersareforthetoast operatorwhentherewasaloadof 48simultaneouspaths.
Althoughtheselatenciesmaybeacceptablein somesce-narios(like asynchronouse-mail to voiceconversion),theyare quite high for regular call setup. We expect to bringthesenumbersdown in thenext roundof implementation.
5. RelatedWork
We have comparedour architectureto existing onesinseveralcontexts in theprevioussections.Thissectionsum-marizesthesecomparisons.
There hasbeena lot of recentcommercialinterestinserviceintegration. Thereareseveral efforts that providepartial integration of communicationservices. Thesein-clude serviceslike e-mail/voice-mail integration [12, 15],e-mail/fax integration [10, 14], etc. Someprovide only“name” integration,andno “type” integration. Nonepro-vide trueany-to-any, extensibleintegrationor personalizedredirectionacrossall devices.
The Active Messengerproject [22] provides elaboratemechanismsfor delivery of messagesto the user at anyend-point. It concentrateson this functionality – which isanimportant,but orthogonalproblemto whatwe focuson.Wepresentaninfrastructurecomponentbasedapproachforextensibleintegrationon top which functionalitieslike theActiveMessengeragentcanbebuilt.
There have also beenrecent researchefforts with re-spectto PersonalMobility. TheMobile PeopleArchitecture(MPA) [28] is an architecturebasedon a PersonalProxy(PP)for achieving person-level routing; thePPis responsi-ble for handlingcommunicationon theuser’s behalf.Tele-phony Over Packet networkS(TOPS)[1] is anarchitecturethatprovidesredirectionof incomingcommunicationusingaTerminal-Tracking-Server.
Theclearidentificationandseparationof the functionalcomponentsin design, implementation,and most impor-tantly, deployment,is uniqueto our architecture.TheUni-versalInboxarchitecturemapsthesecomponentsto asetofreusablenetwork components.As we arguedin Section3,thishasimmenseadvantagesin termsof extensibility;espe-cially with respectto thedatatransformationcomponent.
MPA andTOPSidentify componentsfor userpreferencemanagementandnametranslation. MPA also identifiesacomponentfor datatransformation(theconversiondrivers).
However, the componentsare tightly coupledandarenotrealizedas reusablenetwork services. This restrictstheextensibility andscalabilityof thesearchitectures.For in-stance,in the caseof the MPA, the PPhasto know aboutall possibledataformats(i.e., have the appropriate“Con-versionDrivers”). If thereis anew servicewith anew data-formatthatneedsto beintegratedwith thesystem,thePP’sof all usershave to bechangedto accommodatethis. Withthe UniversalInbox, sincethe datatransformationcompo-nentis an independentthird-partyservice,only this hastochange. All usersfrom all devices can now usethe newservice(Section3 provided specificexamplesto illustratethis).
Furthermore,the UniversalInbox usesthe notion of apathof datatransformation[20], which providesanexten-sible datatransformationmechanism.This givesus addi-tionalextensibility features.
Finally, UMTS [29] is an ETSI standardizationeffortthat includesthird generationPCSservices;personalmo-bility acrossdevice end-pointsis one of its features. Itmakesuseof IntelligentNetwork componentsfor realizingits functionality [2, 4]. Despitebeinga highly scalablear-chitecturebasedon the SS7network, it doesnot identifyexplicit componentsfor preferencebasedredirectionor datatransformation.Furthermore,its SS7basedarchitecturehasimplicationson thehighcostof entryto addingnovel func-tionality [18].
6. Conclusionsand Future Dir ections
Providing personalizedintegration of heterogeneoususerdevices is of crucial importancefor communicationmanagement.Therehasbeena lot of recentcommercialaswell asacademicinterestin integratingusercommunica-tion end-points.In thispaper, wetakeacloselook atwhatittakesto provideany-to-any integrationin anextensibleandscalablefashionin anintegratednetwork. We identify threecrucialcomponentsfor suchan integration,andpresentanarchitecturemappingtheseto reusableinfrastructureser-vices.
The key strengthof our architectureis the extensibil-ity of thesystem.Thenetwork-centricapproachmakesthesystemeasyto extendto new end-pointsandservices;thereusablecomponentsin the coreprovide the “glue” to in-tegratewith all existing end-points. Easeof extensibilityalso comesfrom the flexible path model upon which thedatatransformationcomponentis built. Easeof deploymentin thearchitecturecomesfrom thefactthatservice-specificaccesspointscanbe deployed independently;the user’s e-mail serviceprovidercanbuild anaccesspoint independentof theirpagerserviceproviderandtheusercanstill managethesetwo servicesin anintegratedfashion.
Personalization is provided by a central redirection
agentratherthanat the edges;this meansthat it is easytopersonalizethemanagementof all of a user’s devices.Ourinitial performanceexperimentsshow that it is indeedpos-sible to scalethe infrastructurecomponentsto a largeusercommunity, which would be requiredwhen thesecompo-nentsareimplementedasreusableservices.
Our implementationof the mobility featureshasgivenus experiencewith building and extendingservicesusingthecomponentbuilding blocks. A varietyof issuesremainfor futurework.
We have assumeda cluster-basedimplementationof theAPC service in which data pathsare within the cluster.However, theremaybecaseswhenthis is not possibleanda pathhasto be stretchedacrossthe wide-area.Thereareinterestingissuesof path-controlandmonitoringin suchascenario. Also, infrastructureservicesthat have multipleinstancescantake advantageof theInternettopologyto bestrategically placedsuchthat a serviceinstanceis alwaysavailablefor theclient of theservice.We arecurrentlyex-ploring this issue.Finally, we havenot addressedissuesre-latedto securebilling for servicesin theintegratednetwork,which arecrucialfor a realdeploymentof thesystem.
Acknowledgements
We wish to thank all the membersof the ICEBERGproject for the healthydiscussionsthat helpedin refiningthe design. We aregrateful to Tina Wong, Drew Roselli,SanjayRao, and the anonymousreviewers for their com-mentsonearlierrevisionsof thepaper. RahulBiswasimple-mentedthePreferenceManagerGUI. EmreKiciman, Bar-baraHohlt, andZ. Morley Maoworkedon theimplementa-tion of theAPCservice.Thiswork is partof theICEBERGprojectat U.C.Berkeley supportedby Ericsson,Sweden.
References
[1] N. Anerousisandet.al. TheTOPSArchitecturefor Signal-ing, DirectoryServicesandTransportfor Packet Telephony.In The8th InternationalWorkshopon Networkand Oper-ating SystemsSupportfor Digital Audio andVideo(NOSS-DAV), 1998.
[2] E. Buitenwerfandet.al. UMTS: FixedNetwork IssuesandDesignOptions.IEEEPersonalCommunicationsMagazine,February1995.
[3] J. Degener and C. Bormann. GSM Codec Library,University TU-Berlin, FB-Informatik. http://kbs.cs.tu-berlin.de/jutta/toast.html.
[4] N. FaggionandC. T. Hua. PersonalCommunicationsSer-vicesThroughtheEvolutionof FixedandMobileCommuni-cationsandtheIntelligentNetworkConcept.IEEENetwork,Jul/Aug1998.
[5] Festival. The Festival Speech Synthesis System.http://www.cstr.ed.ac.uk/projects/festival.html.
[6] A. Fox andet.al.ScalableNetwork Services.In Proceedingsof the16th ACM Symposiumon Operating SystemsPrinci-ples(SOSP-16), St.Malo, France,Oct 1997.
[7] S.Gribble.Simplifying Cluster-BasedInternetServiceCon-structionwith ScalableDistributed Data Structures. PhDCandidacyQualifyingExam,U.C.Berkeley, April 1999.
[8] S. D. Gribble and et.al. The MultiSpace: an Evolution-ary Platformfor InfrastructuralServices.In UsenixAnnualTechnical Conference, June1999.Monterey, CA.
[9] J. HomaandS. Harris. Intelligent Network Requirementsfor PersonalCommunicationServices. IEEE Communica-tionsMagazine, February1992.
[10] http://info.ox.ac.uk/fax/. Email to Faxat Oxford University.[11] http://ninja.cs.berkeley.edu/.TheNinja Project.[12] http://planetarymotion.com/.PlanetaryMotion’s CoolMail
Service:Email byComputeror Phone.[13] http://www.databeam.com/h323/h323primer.html. A Primer
on theH.323SeriesStandard.[14] http://www.faxaway.com/.Faxaway:ThePremierEmail to
Fax Service.[15] http://www.onebox.com/.Onebox: Voicemail,Email, and
Fax.[16] http://www.scriptics.com/java. TCLJavaIntegration.[17] http://www.thinklink.com/.ThinkLink.[18] D. S. Isenberg. The Dawn of the Stupid Network. ACM
Networker 2.1, pages24–31,February/March1998.[19] V. JacobsonandS. McCanne. VAT MboneAudio Confer-
encingSoftware. ftp://ftp.ee.lbl.gov/conferencing/vat.[20] A. D. Joseph,B. Hohlt, R. H. Katz, andE. Kiciman. Sys-
temSupportfor Multimodal InformationAccessandDeviceControl.Work in Progress,WorkshoponMobile ComputingSystemsandApplications(WMCSA), 1999.
[21] C. N. Lo, R. S. Wolff, andR. C. Bernhardt. An Estimateof Network DatabaseTransactionVolumeto SupportUni-versalPersonalCommunicationsServices.In First Interna-tional Conferenceon Universal PersonalCommunications(ICUPC ’92), 92.
[22] S. J. Marti. Active Messenger:Email Filtering andMobileDelivery. Master’s thesis,MIT MediaLaboratory, Septem-ber1999.
[23] P. Mockapetris.DomainNames- ImplementationandSpec-ification. IETF. Requestfor Comments:1035, Nov 1987.
[24] M. Mouly andM. B. Pautet. TheGSMSystemfor MobileCommunications, chapter2, pages102,133. Cell & Sys,1992.
[25] M. Mouly andM. B. Pautet. TheGSMSystemfor MobileCommunications, chapter3, pages150–153. Cell & Sys,1992.
[26] R. Pandya. Emerging Mobile andPersonalCommunictionSystems.IEEE CommunicationsMagazine, June1995.
[27] M. Rahnema.Overview of TheGSM SystemandProtocolArchitecture.IEEECommunicationsMagazine, April 1993.
[28] M. Roussopoulosandet.al. Personal-level Routing in theMobile PeopleArchitecture.In Proceedingsof theUSENIXSymposiumonInternetTechnologiesandSystems, Oct1999.
[29] A. Samukic.UMTS UniversalMobile TelecommunicationsSystem: Developmentof Standardsfor the Third Genera-tion. In IEEE Transactionson Vehicular Technology, vol-ume47,Nov 1998.
[30] H. Schulzrinne.A Comprehensive MultimediaControlAr-chitecturefor the Internet. In Proceedingsof InternationalWorkshopon Networkand Operating SystemSupportforDigital AudioandVideo, May 1997.
[31] M. Zaid. PersonalMobility in PCS. IEEE PersonalCom-munications, FourthQuarter1994.