presentedin12asadesignmethodologyforadaptiveandmultimedianetworksRAMONprovidesarstexampleofuseofthismethodologyTheremainingofthepaperisorganizedasfollowsInSection2wedescribetheRAMONFunctionalArchitec ID: 896635
Download Pdf The PPT/PDF document "TheRAMONmodulearchitectureframeworkandpe..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
1 TheRAMONmodule:architectureframeworkandp
TheRAMONmodule:architectureframeworkandperformanceresultsA.Roveri1,C.F.Chiasserini2,M.Femminella3,T.Melodia1,G.Morabito4,M.Rossi5,I.Tinnirello6(1)UniversityofRomeLaSapienza;(2)PolytechnicofTurin;(3)UniversityofPerugia;(4)UniversityofCatania;(5)UniversityofFerrara;(6)UniversityofPalermoAbstract.AdesignstudyofaRe-con gurableAccessModuleforMo-bileComputingApplicationsisdescribed.Afterapresentationofitscross-layeredarchitecture,ControlParameters(CPs)ofthemoduleareintroduced.ThesetofCPsbothdescribesthefunctionalstateofthecommunicationprocessinrelationtothetime-varyingtransportfacili-tiesandprovides,asinputofsuitableAlgorithms,thecontrolinformationtore-con gurethewholeprotocolstackforfacingmodi edworkingcon-ditions.Thepaperalsopresentsthestructureofthesimulatorrealizedtodemonstratethefeasibilityofthedesignguidelinesandtoevaluaterecon gurabilityperformances.1IntroductionThispaperpresentsa rstinsightinthedesignofaRe-con gurableAccessmoduleforMObilecomputiNgapplications(calledRAMONinthesequel)anddiscussessomepreliminaryresultsofafeasibilitystudyofthismodulewhichisbeingcarriedoutwithinanItalianresearchprogram1,withtheparticipationofsixacademicresearchgroups2.TheframeworkofRAMONisgivenbymobileusersinaTCP/IPenviron-ment(mobilecomputing).Themobilityisallowedindi erentcommunicationenvironments(ReferenceEnvironment,RE).TheseREsareidenti edinaWANcellularsystem(e.g.,UMTSorGPRS)andinalocalareaaccesssystem(e.g.,IEEE802.11orBluetooth).Inwirelesscommunications,muche ortwillhavetobeputintheabil-itytore-con gurealllayersofthecommunicationprocesstothetime-varyingtransportfacilities,inordertoassuretherespectofQoS(QualityofService)requirements.Theadaptabilitytodi erentcommunicationenvironmentsledustoovertaketheOSIlayeredapproachandtoadopttheideaofcross-layeringdesign,whichappearstobepart
2 icularlyappealingtoenabledynamicoptimiza
icularlyappealingtoenabledynamicoptimiza-tionamongalllayersofthecommunicationprocess.Theideahasalreadybeen1TheRAMONprojectwaspartiallyfundedbyMIUR(ItalianMinistryofResearch).2TheaddressofthereferenceAuthoris:roveri@infocom.uniroma1.it presentedin[1],[2]asadesignmethodologyforadaptiveandmultimedianet-works.RAMONprovidesa rstexampleofuseofthismethodology.Theremainingofthepaperisorganizedasfollows.InSection2wedescribetheRAMONFunctionalArchitecture.Section3de nestherelevantControlPa-rametersthatconstitutethebasisofthere-con gurationactionandthemainalgorithmswhichperformit.Section4presentstheoverallRAMONsimulatordevelopedinthens-2framework[3]todemonstratethefeasibilityofthedesignguidelinesandtoevaluatetherecon gurabilityperformances,whileSection5containssomesamplesofperformanceresults.2TheArchitectureRAMONallowsthedeploymentofcontrolalgorithmswhichareindependentofthespeci cREconsidered.Amobilestation(MS),equippedwithRAMON,be-comesavirtualMS,i.e.anMSwhichsupportsabstractfunctionalitiescommontoalltheREs.Suchfunctionalitiesareobtainedfromthespeci cfunctionalitiesofeachRE,bymeansoftranslationentities,asdescribedbelow.Figure1showstheRAMONfunctionalarchitecture.ItincludesaCommonControlplane(CC-plane)andanAdaptationplane(A-plane),whichisdividedinasmanyparts(A/RE-i)asthenumberofdi erentREsinvolved.InthecaseofFigure1thenumberofdi erentREsisletequaltotwoforthesakeofsimplic-ity.BelowtheA-plane,NativeControlfunctionalities(NC-plane)foreachRE(denotedasNC/RE-iforthei-thRE)arelocated.AnRE-independentservicedevelopmentAPI(ApplicationProgrammingInterface)iso eredtotheoverly-ingApplicationlayer.CC-planefunctions,whicharealsoRE-independent,aregroupedinthreefunctionalsets,accordingtotheclassicalmodeladoptedforwirelesscommu-nications:i)RadioResourceControl(RRC-c);ii)SessionControl(SC-c);
3 iii)MobilityManagement(MM-c).Fig.1.Overa
iii)MobilityManagement(MM-c).Fig.1.Overallsystemarchitecture.TheA-planetranslates:1)PrimitivesexchangedbetweentheCC-planeand theNC-planeforeachRE;2)ControlParameters(CP)datapassedfromtheNativeUserplane(NU-plane)totheCC-plane.Twodi erenttypesofinterfacescanbeidenti ed:i)the interface,betweentheCC-planeandtheA-plane;ii)the interface,betweentheA-planeandtheNC-planeofeachRE.Figure2completesFigure1.InitsrightparttheCC-planeandtheA-planearedepicted,withtherelevant and interfaces.Initsleftpart,whichisconcernedwithtwogenericREs,therelevantNC-planesandNU-planesareshown.Figure2helpsusshowingthewaytheSC-c,MM-candRRC-cfunctionalitiesinteractwiththecorrespondingSC-i,MM-iandRRC-i(i=1,2)ofthetwoREsthroughthetranslationperformedbytheAplanes(A/RE-1,A/RE-2).There-lationsbetweentheNC-planesandNU-planesarehighlightedandparticularlyhowtheSC-i,MM-iandRRC-ifunctionalitiesarerelatedwithPhysical(PHY-i),MediumAccessControl(MAC-i)andRadioLinkControl(RLC-i)functionsisshown.Finally,Applications,TCP/UDPandIPlayers,whicharepartoftheNU-plane,directlyinteractwiththeCC-plane.Fig.2.BasicinteractionsamongControlandUserplanes.3Recon gurabilityParametersThemainideaistodynamicallyadaptthewholestacktotheperceivedQoSbymeansofadequatecontrolactions.QoSmeasurementsarepassedtotheRA-MONentitybymeansofCPdata. Cross-layerinteractionrequirescontrolinformationsharingamongalllay-ersoftheprotocolstackinordertoachievedynamicresourcemanagement.Itmaybeperformedintwodirections:i)upwardinformationsharing:upperlay-ersparametersmaybecon guredtoadapttothevariableREcharacteristics;ii)downwardinformationsharing:MAC,RLCandPHYlayerparameterscanadapttothestateofTransportandApplicationlayerparameters.Thus,e.g.,thebehavioroftheTCPcongestionwindowmaybeforcedtoadapttothetime-varyingphysicalchannelcharacteristics(upward),whilelow
4 erlayerparametersmaybere-con gured,witht
erlayerparametersmaybere-con gured,withtheaimofservingdistinctapplicationswithdi erentQoSrequirements(downward).AsshowninFigure3,CPdata\rowfromalllayersoftheNU-planeofeachREandareprocessedbyAlgorithmsrunningintheCC-plane.TheoutputoftheAlgorithmsconsistsofCommandPrimitives,whicharepassedtoalllayersoftheprotocolstack.Forlowerlayers,whichareRE-dependent,theseprimitiveshavetobeinterpretedbythepertinentA-plane;forhigherlayers,whicharetypicaloftheInternetstack,theprimitivescanactwithoutanymediation.Fig.3.Information\rowsinRAMON.Thee ectoftheCommandPrimitives,inconcurrencewiththevariationsoftheREtransportcharacteristics,givesrisetomodi cationsintheperceivedQoS.Thesemodi cationscausecorrespondingchangeoftheCPdata.TheCC-planeperformsre-con gurationactionsonlyiftheyentailappreciableimprovementsintheQoSperceived.ThemostimportantAlgorithmsadoptedintheRAMONdesignare:{TheHandoverAlgorithm;{SessionControlAlgorithm;{QoS&MMAlgorithm; {RRCAlgorithmforErrorControl;{RRCAlgorithmforResourceSharingControl.The rsttwoalgorithmswillbeanalyzedrespectivelyinSections3.1and3.2;theotherthreewillbebrie\rydescribedinthefollowing.QoSandMMcapabilitiesarecarriedoutbymeansoftheMobileIPprotocol,improvedwithanAdmissionControlfunction.ThislastiscalledGRIP(GaugeandGateRealisticProtocol),isdescribedin[7]andoperatesinaDi erentiatedServicesframework.Inaddition,weassumedthatamicro-mobilitystrategy[8]isadoptedwithinthewirelessdomain:thescopeistohidelocalhando sfromHomeAgent/CorrespondentNodes,thusreducinghando latency.Topreserveinformationintegrityofpackettransmissionovertheradiochan-nelwhilemeetingthedesiredQoSandenergyconstraints,analgorithmforErrorControlhasbeendevelopedwithintheRRCfunctionalset,whichissuitableforaUMTSenvironment:itprovidesoptimaloperationalconditionsandparametersettingattheRLClayer.The
5 performanceresultsoftheapplicationofthea
performanceresultsoftheapplicationofthealgo-rithmtotheUMTSREarebeingpublished[10]andamodulewhichimplementsitintheRAMONoverallsimulatorhasbeendeveloped.Anopen,re-con gurableschedulingalgorithmcalledCHAOS(CHannelAdap-tiveOpenScheduling)hasbeende ned,whichispartoftheRRC-cfunctionalset.TheAlgorithmde nesaschedulingstrategyforecientresourcesharingcontrol.Itisadaptivetotracconditionsandphysicalchannelconditions.Dif-ferentCPsmaybechosentorepresentbothvariables.Tracconditionsmayberepresentedbytransmissionbu eroccupancyorqueueageassociatedtopacketsinthetransmissionbu ers;physicalchannelconditionsmaybeexpressedbyav-eragedSignaltoInterfenceRatio(SIR)and/orPacket/FrameErrorRatio.ThebasicCHAOSprinciplescanbeappliedinaRAMONmoduleresidinginaVBSmanagingradioresourcesofdi erentREs.Thespeci cadaptationsstudiedforUTRA-TDDandBluetooth(whosedescriptioncanbefoundin[11])correspondtoA-planeentitiesoftheRAMONarchitecture.3.1HandoverAlgorithmRAMONincludesanabstracthandoveralgorithm,runningattheVirtualMS(VMS),basedonthevirtualizationofthefunctionsnecessaryforMobilityMan-agement.Thisoperationallowsmakinghandoverservicesprogrammableandindependentoftheunderlyingtechnologies.Inare-con gurablewirelessscenario,theselectionofthe\best"accesspointatanymomentisnotsimplyrelatedtothephysicalchannelquality,butimpliesalsoatechnologychoiceasatrade-o betweenperformance,cost,powercon-sumptions,etc.Moreover,theroamingacrossdi erentsystemsrequiressolvingaddressingandauthenticationproblems,maintainingalowlatencytopreventtheadversee ectsofTCPcongestioncontrol.Inordertodevelopaplatform-independenthandoveralgorithm,similarlyto[4],[5]wehavedecoupledtheseproblems.ByhidingtheimplementationdetailsoftheMMalgorithmsfromhandovercontrolsystems,thehandoverdecision canbemanagedseparatelyfromhandoverexecution,sothatthe
6 samedetectionmechanismscaninterfacewithm
samedetectionmechanismscaninterfacewithmanydi erentaccessnetworks.ThealgorithmisbasedonagenericMobileControlledHandover(MCHO)style:handoverdecisionsandoperationsarealldoneattheVMS.RAMONkeepstrackofalistofVirtualBaseStations(VBS)initscoveragearea.TherationaleisthatsomeREsdonotprovideMCHOcapabilities.Therefore,theentireREisconsideredasauniqueVBS.Conversely,forMCHOsystems,aVBScoincideswithaBS.Periodically,foreachVBS,theVMScollectsCPsasQoSmeasures(possiblyqueryingtheVBS)andestimatescellloadcondition.Accordingtothede nitioncriterionofthebestVBS,ifthebestservingVBSisnottheoneinuseforagivenperiodoftime,theVMShand-o stoit.Wecanidentifythreemainlogicalfunctionalblocks:i)theuserpro lespec-i cation,whichre-con guresthedecisionmetrics,accordingtotheuserrequire-ments;ii)themeasurementsystem,basedonsystem-dependentavailablefunc-tionsandsignaling;iii)thedetectionalgorithm,whichcomparesabstractper-formancemetricscomputedonthebasisofthemeasurementsandoftheuserpro le.ThecostofusingaBSnatagiventimeisfunctionoftheavailablebandwidthBn,therelatedpowerconsumptionPn,thecostCnofthenetworktheBSnbe-longsto.Whilethelasttwoparametersareeasytocompute(mobilehostbatterylifeandservicetypecost),thebandwidthparameterismorecomplex.Inordertoaccountfortherealavailablebandwidth,channelqualityperceivedbytheMSandcelloccupancystatushavetobeconsidered.ThecostfunctionoftheBSnisthenevaluatedas:fn=wbN(1=Bn)+wpN(Pn)+wcN(Cn)(1)wherewb,wpandwcaretheweightsofeachparameter,whichsumto1,andN(x)isthenormalizedversionoftheparameterx.ThereciprocalofthebandwidthisconsideredinordertominimizethecostfunctionofthebestaccessBS.Weightscanbemodi edbytheuseratrun-time,andcanbesettozeroforthoseparametersthatarenotofconcerntotheuser:e.g.,ifhighperformancehastobepursued,wecanassignwb=1,wp=0andwc=0.Thus,byminimizingthecostfunc
7 tion,weachieveloadbalancingacrossdi eren
tion,weachieveloadbalancingacrossdi erentREs.3.2SessionControlAlgorithmDuetothelowMobileIPperformance,theMSmigratingfromaREtoanothermaybeunreacheablefortimeperiodsoftheorderofseconds,whichconsiderablyimpactstheTCPoperation.Inparticular,severalconsecutiveRTOs(Retrans-missionTimeOut)occur.ThisresultsinaverylowvalueoftheSlowStartThreshold(ssthresh)which,uponeachRTOexpiration,isupdatedasfollows:ssthresh=max(cwnd=2;2MSS)(2) wherecwnddenotesthecurrentCongestionWindow.Therefore,astheinter-REhandoverissuccessfullycompleted,thesenderimmediatelyenterstheConges-tionAvoidancephaseandcwndincreasesslowly.Thiscauseslowthroughputperformance.Inordertosolvethisproblem,theTCPsenderimplementationhasbeenmodi ed,stillmaintainingcompatibilitywithstandardTCPimplementations.Weobservethat,afteraninter-REhandover,theconnectionpathmaychangedramatically.Consequently,whattheTCPsenderlearnedintermsofavailablebandwidthandestimationsoftheRTT(RoundTripTime)andRTOisnotvalidanymore.Basedontheaboveobservation,aftertheinter-REhandoveriscom-pleted,theTCPsenderresetsitsinternalparameters(i.e.,ssthresh,SmoothedRTT,andRTO),andentersintotheso-calledFastLearningphaseduringwhichitrapidlyestimatestheavailablebandwidthandtheRTTcharacterizingtheconnectioninthenewRE.Moreover,inordertoavoiduselesssegmenttrans-missionswhichwouldonlyresultinpowerconsumption,theTCPsenderstopstransmittinganydataasthehandoverbeginsandresumesasthehandoverissuccessfullycompleted.Theinformationaboutthebeginningandtheendofhandoversisprovidedbycommandprimitives.TheaboveAlgorithm[6],whichwillbereferredtoasTCP-RAMONinthesequel,hasbeenintegratedintheoverallRAMONsimulator,andise ectivewhentheMS,actingasamobilehost,istheTCPsender.Otherwise,asimilarbehaviorcanbeobtainedasfollows.Beforeinitiatingthehandover,theMSgeneratesanACKwhichinformstheTC
8 PsenderthattheReceiverWindow(rwnd)isequa
PsenderthattheReceiverWindow(rwnd)isequalto0.ThisresultsinafreezingoftheTCPsenderandavoidsconsecutiveRTOexpirations.Whenthehandoveriscompleted,theTCPreceivergeneratesanewACKwiththeoriginalvalueofrwnd:thisoccurrenceresumesthecommunication.4TheSimulativeApproachInthissectiontheRAMONsimulator(Figure4)isdescribedwithreferencetoUMTS-TDDandBluetoothREs.An802.11implementationhasalsobeende-veloped.Thesimulatorisbasedonthenspackage[3](ver.2.1b7a).Speci cally,modi cationshavebeencarriedouttotheWirelessNodeobject(MobileNodeclass).OneprotocolstackforeverysimulatedREiscreatedinthesameMo-bileNodeobject.TheRAMONmoduleandtheA-planemodulesareinterposedbetweenAgents(RTAgent,MIPAgent,etc.)andradioaccesslayers(LL,MAC,etc.).OntheleftpartofFigure4theUMTS-TDDprotocolstackisshownwithitsspeci cAdaptationplane(A/RE-UMTSin gure),whereastheBluetoothstackisontherightsidewithitsA-plane(A/RE-BT).OntopofthestackstheRAMONmoduleisdirectlylinkedtotheTCP(orUDP)layer,totheMIPlayer(MobileIP)andtotheNOAHroutingAgent(NOnAdHocroutingagent[13]).TheUMTS-TDDprotocolstackhasbeendevelopedforthisproject.TheBluetoothprotocolstackisderivedfromthensBluehocsimulator[12]andmodi edto Fig.4.Overallsimulatorarchitecture.adapttheBluetoothnodeobjectBTnodetothensMobileNodeobject.The interfaceinFigure4de nesthemessagesexchangedbetweenCC-planeandA-planes.Thefunctionsofthe interfacecanberelatedtotheCommandPrim-itivesandtheparameterstheyexploittotheCPs.Alistofthemostimportantofthesefunctionsfollows:{get(parametersname):getstheparametersnameparametervalue.{attach():isusedtocreateanIPcontextandtoregisterthenodetotheForeignAgent(FA).{detach()deletesregistrationfromtheFA.{monitor(RE):returnsaqualitymetricfortherequestedRE.{set(parametersname,value):setsthevaluevaluetoparametersnameparameter.{send(packet,options){receive(option
9 s)Inparticular,the\get"functionisusedtor
s)Inparticular,the\get"functionisusedtoreadtheCPsfromtheA-planesforoptimizationpurposes.CPsoriginatedatdi erentlayerscanbeassociatedtodi erentoptimizationtasks:i)physicallayerCPsarerelatedtopowercontrolandbatterylifesaving;ii)linklayerCPsaredirectlyconnectedtolinkrelia-bilityandpacketdelay;iii)transportlayerCPsaredirectlyrelatedtotheQoSperceivedfromtheuserapplicationintermsofpacketdelayandthroughput.The\set"functionisneededtopasssomevaluestotheA/RE-imodules:infact,withthisprimitive,someCPscanbemodi edbytheCC-plane.Boththe\set"andthe\get"functionsarealsode nedfortheinteractionsbetweentheCC-planeandRE-independentupperlayersprotocols.Theotherfunctionsde- nedaboveareCommandPrimitives(forthe interface).Twomoreprimitives(namedrespectivelystarthandovernotification() andendhandovernotification())arede nedforinteractionbetweentheCC-planeandthetransportlayer.The rstonenoti estheTCPaboutthebeginningofthehandoverwhilethesecondonenoti estheendofit.ThemostimportantCPspassingthroughthe interfacearebrie\rydiscussedinthefollowingforthemainlayersinteractingwithRAMON.Physicallayer.CPsdetectableatsuchlayerarestronglydependentontheconsideredRE.AveryusefulCPisthebatterylevel(BATLEVEL),usedtomax-imizetheMSlife,e.g.,byattachingtheMStothelesspowerdemandingRE.Moreover,TransmittedPower(TXPOWER)andSIR(SignaltoInterferenceRatio)(SIR)measurements,ifavailable,areusedtodetecttemporarylinkfailuresorhighinterferenceconditions:e.g.,ifthephysicalchannelinagiveninstantisdetectedtobeinaninterferencepronesituation,theLinklayercanbesetina\wait"statustoavoidenergywastage.Linklayer.Adescriptionoftheerrorprocessatsuchlayerissigni cantinor-dertocharacterizethepacketerrorprocessa ectingtheApplicationlayer.SuchadescriptioncanbeachievedbytranslatingtheLinklayerpacketsuccess/failuretransferprocessintoasimpleM
10 arkovModel[14],whichisanalyticallytracta![arkovModel[14],whichisanalyticallytracta](896635/arkovmodel-14-whichisanalyticallytractab.jpg "arkovModel[14],whichisanalyticallytracta")
arkovModel[14],whichisanalyticallytractableandREindependent;henceREindependentalgorithmscaneasilybedeployedwhichexploitsuchmodel.TheCPsforthemodelsare:lossprobabilityatthelinklayer(PLOSSLINK),linklayerpacketsize(LINKPACKETSIZE),averagebursterrorlengthatlinklayer(BURSTERR)andaveragelinkpacketerrorprobability(ERRPR).Otheruse-fulCPsarethemaximumnumberofretransmissionsperpacketallowedinthelinklayer(MAXLINKRETR)andtheaveragenumberofretransmissionspercor-rectlytransmittedpacket(AVGLINKRETR);thelastoneisrelatedtotheenergyspentperusefulinformationbit,i.e.,theamountofenergywastedduetoLinklayerretransmissions.Transportlayer.Atthislayer,theMSshouldbeabletocollectinformationregardingthepacketdelay/errorprocess.WhentheTCPprotocolisconsidered,inadditiontothepacketerrorrate,itcommunicatestoRAMONtheaverageandinstantaneousThroughputvalue(AVGTHandACTTH),theestimatedRoundTripTime(RTT)andtheactualRTO.TheseCPsareusedtocontrolthebehaviorofTCPstatevariablesandtoavoidtheirincorrectsettingaspacketerrorsoccur.Inparticular,itiswellknownthatTCPreactstopacketlossesasifacongestionhadoccurred,i.e.,byreducingthemaximum\rowthatthesenderisallowedtoputintothenetworkatatime.However,inawirelessenvironmentthisisnotthecorrectwaytoproceedbecauseerrorsa ectingawirelesslinkareveryoftentransientanddonotrepresentatallameasureofnetworkcongestion.OnthecontrarytheyareameasureofthetemporarylinkQoS.Moreover,performancemeasuredatthislevelisdirectlyrelatedwiththeQoSperceivedbytheuser,soitcanbeweightedinacostfunctioninordertoderiveanestimateoftheactualQoS.SuchanestimateisthencomparedagainsttherequiredQoSandusedbyRAMONalgorithmsintheirdecisionaltasks. 5PerformanceissuesThemostmeaningfulsimulatedsituationsare:1)Forcedinter-REHandover.2)User-driveninter-REHandover;ThesescenariosarerelevantintheRAMONcontextbecausethe
11 yeasilyshowhowaCommonControlPlane(RE-ind
yeasilyshowhowaCommonControlPlane(RE-independent)canreacttovariationsintheREsithandles,perceivedbymeansofControlParameters,foroptimizationpurposes.Inthe rstscenariotheVMSlosesconnectivityandisforcedtoattachtoanotherREtomaintainsessioncontinuity.InthesecondonetheVMSisinthecoverageareaoftwodi erentREs(UMTSand802.11)atthesametimeandchoosesthebestREevaluatingacostfunctionasdescribedinSection3.1.5.1ForcedHandoverInthisSectionsomesimulationresultsrelevanttoaninter-REforcedhandoverarepresented.ThescenarioinvolvesaUMTSBS,whichistheMIPHomeAgent(HA),andaBluetoothBS,whichhastheroleofForeignAgent(FA).AForcedHandoverbetweentheformerandthelatterissimulated.Figure5showsthetemporalbehaviouroftheTCPsendercwndwhenTCPNewRenoisusedandwhenthemodi edTCP-RAMONisused.WhenTCPNewRenoisused,multipleRTOsexpireduringthehandoverandleadtothessthreshtoitsminimumvalue.Thus,whenthehandoverends,theTCPentersinthecongestionavoidancephaseandthusitscwndincreasesslowly.WhenTCP-RAMONisused,assoonastheCC-planedetectsalossofcon-nectivity,astarthandovernotification()primitiveisissuedtotheTCPlayer.Thisfreezesthevalueofssthreshtotheonedeterminedbythelastcon-gestioneventoccured.Accordingly,timeoutsexpiringduringthehandoverdonotimpactthevalueofssthresh.Oncetheendhandovernotification()isreceivedthevalueofsstreshissetequaltotheonedeterminedbythelastcon-gestionevent.Thus,TCPenterstheslowstartphase(itdoesnotenterthecongestionavoidancephaseuntilcwndreachesthessthreshvalue).Inthesesim-ulations,bu ersareconsideredtobein niteandtheinitialssthreshvaluehasbeensetto20whichisatypicalvalueinseveralTCPimplementations.5.2HandoverCustomizationInthisSectionwepresentsomesimulationresultsrelevanttouser-drivenhan-dovers.Ourpurposeistodemonstratehowuserpro lespeci cationsa ecthan-dovertriggeranddetectionphases.Infact,theoptimizat
12 ionofdi erentperfor-mance guresrequiresd
ionofdi erentperfor-mance guresrequiresdi erentchoicesintermsofREattachment/detachmentpolicy.Forexample,ifusermaingoaliscostsaving,connectionstolow-priceac-cesspointshavetobemaintainedaslongaspossible,evenifbettertransmission Fig.5.UMTS-BluetoothForcedHandover.conditions(intermsofbandwidthorchannelquality)towardsotherstationsareavailable.Inoursimulationsweconsideranareainwhichheterogeneousradioaccesstechnologies(namelyUMTSand802.11),experiencingdi erenttraccondi-tions,overlap.Inparticular,wehaveconsideredasimplenetworktopology:four802.11BSs(referredtoasBS2,BS3,BS4,BS5)areplacedattheverticesofasquareandaUMTSBS(BS1)isplacedinthecentre.Thesideofthesquareissetto600m,whilethecoverageareasofthe802.11andUMTSBSsaresetrespectivelyto200mand1000m.Channelratein802.11cellsissetto2Mb/s.802.11BSshaveadi erentnumberofattachedusers:fourmobilenodesareconnectedtoBS2andBS4,whileninemobileusersareconnectedtoBS3andBS5.Inthesimulationrun,aRAMONmobilenode,involvedina6Mbytes letransferfromthe xednetwork,movesclock-wiseat6m/salongthesquarestart-ingfromavertex,forexamplefromBS2.AlthoughduringthesimulationtimeRAMONnodeiscoveredbyBS1,handoverto802.11BSscanbeperformedinordertosavepowerorreducecost.Nevertheless,anhandovertowards802.11BSsimpliesaloweramountofavailablebandwidthbecauseoftheirloadcondi-tions.Therequiredusertrade-o isexpressedbythedecisionmetric(Section3.1)settings.Wecomputesuchametricconsideringdistance,priceandbandwidtho eredbyeachBS.Inordertomakedi erentsystemparameterescomparable,wenormalizeeachparameterasfollows:distanceisexpressedastheratiobe-tweenactualdistanceandmaximumcoverageradius,priceandbandwidthare normalizedwithrespecttothemaximuminter-REvalues.Inparticular,weas-sumethatthecosttotransfer1kbyteofdatais1forUMTS,0.5for802.11.Inoursimulations,wesetthemetricdistanceweig
13 htto0.5andweobserveFig.6.SelectedBSvssim
htto0.5andweobserveFig.6.SelectedBSvssimulationtime.performanceresultsvaryingthecostandbandwidthweightsaccordingtotherelation:wb=0:5 wc.Considerpreliminarlytheextremesituationsinwhichwewanttominimizethe letransfer-costregardlessofthetransfer-time(wb=0)or,conversely,wewanttominimizethetransfer-timeregardlessofthecost(wc=0).Figure6showsthehandovertriggeranddecisionpoliciesadoptedinthecosideredextremecases.Wereporttheidenti eroftheselectedBSversusthesimulationtime.Inthewbsituation,connectiontoWLANiskeptaslongaspossible,sincethisaccesstechnologyisthecheapest(handoversaretriggeredonlywhentheRAMONnodemovesoutsidethecoverageareaofan802.11BS).Inthewccase,theRAMONnoderemainsconnectedtoUMTSforagreatertime(switchtoWLANoccursonlywhenthedistancefromtherelevantBSisverysmall).Notethat,sinceourmetricaccountsforbothdistanceandload,thepermanencetimein802.11BSsisnotconstantanddependsontheBSconsidered.Thetimeandthecostresultingfortheconsidered6Mbytes letransferisreportedinFigure7versusthewcsetting.This gureshowsthat,bychangingtheweightsofthecostfunction,theRAMONusercane ectivelycon gureitsoptimalcost/performancetrade-o . Fig.7.TimeandCostTradeO .6ConclusionsInthispapertheguidelinesadoptedforthedesignofamoduleabletorecon guredi erentmobilecommunicationenvironmentsforcomputingapplicationsareintroduced.Thepapermostlyconcentratesonarchitecturalissuesandoncontrolinformation\rows.Inparticular,theAlgorithmsthatconstitutetheprocessingcoreofthemodulearebrie\rydescribed.TheintegratedRAMONsimulatorisdescribedandsomeperformanceresultsare nallyshown.7AcknowledgmentsTheauthorswouldliketothankalltheresearchersofthePolytechnicofTurinandoftheUniversitiesofCatania,Ferrara,Palermo,PerugiaandRome\LaSapienza"whoparticipatedtotheRAMONprojectand,notwithstandingtheirimportantcontribution,donotappearasauth
14 orsofthiswork.ReferencesZ.J.Haas,\Design
orsofthiswork.ReferencesZ.J.Haas,\DesignMethodologiesforAdaptiveandMultimediaNetworks,"IEEECommunicationsMagazine.,Vol.39,no.11,November2001,pp106-07.2.T.S.Rappaport,A.Annamalai,R.M.Buehrer,W.H.Tranter,\WirelessCommuni-cations:PastEventsandafuturePerspective,"IEEECommun.Mag.,Vol39,no.11,May2002,pp106-07. 3.NetworkSimulatorhttp://www.isi.edu/nsnam/ns/.4.M.Stemm,R.H.Katz,\VerticalHando sinWirelessOverlayNetworks,"ACMMobileNetworking(MONET)Vol3,n4,1998,pp335-350.5.M.E.Kounavis,A.T.Campbell,G.Ito,G.Bianchi,\Design,ImplementationandEvaluationofProgrammableHando inMobilenetworks,"ACMMobileNetworking(MONET),Vol.6,Sept.2001,pp.443-461.6.G.Morabito,S.Palazzo,M.Rossi,M.Zorzi,\ImprovingEnd-To-EndPerformanceinRecon gurableNetworksthroughDynamicSettingofTCPParameters,"pub-lishedintheseProceedings.7.G.Bianchi,N.Blefari-Melazzi,M.Femminella,F.Pugini,\JointsupportofQoSandmobilityinastatelessIPenvironment,"IEEEGLOBECOM2001,SanAntonio,USA,November2001.8.A.T.Campbelletal.,\ComparisonofIPmicromobilityprotocols,"IEEEWirelessCommunications,February2002.9.M.Femminella,L.Piacentini,\MobilityManagementinaRecon gurableEnviron-ment:theRAMONApproach,"publishedintheseProceedings.10.C.F.ChiasseriniandM.Meo,\ARe-con gurableProtocolSettingtoImproveTCPoverWireless,"IEEETransactionsonVehicularTechnology(toappear).11.A.Baiocchi,F.Cuomo,T.Melodia,A.Todini,F.Vacirca,\Recon gurablepacketschedulingforradioaccessjointlyadaptivetotracandchannel,"publishedintheseProceedings.12.BluehocSimulatorhttp://www-124.ibm.com/developerworks/opensource/bluehoc/.13.JWidmer,\NetworkSimulationsforaMobileNetworkArchitectureforVehicles,"http://www.icsi.berkeley.edu/~widmer/mnav/ns-extension/.14.M.Zorzi,R.R.Rao,\PerspectivesontheImpactofErrorStatisticsonProtocolsforWirelessNetworks,"IEEEPersonalCommunications,vol.6,Oct.