Scalability and Performance Analysis of SIP based Multimedia … ·...

DOI: 10.4018/IJICST.2019010102

International Journal of Interactive Communication Systems and TechnologiesVolume 9 • Issue 1 • January-June 2019

Copyright©2019,IGIGlobal.CopyingordistributinginprintorelectronicformswithoutwrittenpermissionofIGIGlobalisprohibited.

17

Scalability and Performance Analysis of SIP based Multimedia Services over Mission Critical Communication SystemsAshraf A. Ali, University of South Wales, Pontypridd, UK; Hashemite University, Az-Zarqa, Jordan

Khalid Al-Begain, Kuwait College of Science and Technology, Kuwait City, Kuwait

Andrew Ware, Faculty of Computing, Engineering and Science, University of South Wales, Pontypridd, UK

ABSTRACT

Variousstudieshavesuggestedenhancingtheperformanceoflarge-scalesystems,suchasmissioncriticalcommunicationsystems(MCCSs).However,fewhavemodelledandevaluatedtheperformanceofsuchsystemsinawaythattargetsoverallsystemperformanceinrealtime.Moreover,itisnotenoughtodefinetheKeyPerformanceIndicators(KPIs)forasystemwithoutusingthemforsystemperformancemeasurementandperformanceevaluation.TheSessionInitiationProtocol(SIP)andIPMultimediaSubsystem(IMS)bothhaveasetofKPIs,suchastheregistrationprocessdelay,thatcanbeusedtomeasureandthusoptimizeoverallsystemperformance.Thisarticlearticulatesdifferentoptionsforsystemsimulationandevaluation.Theregistrationprocessaffectsperformanceandreflectstheoverallsystemperformance.Thearticleshowshowtheregistrationprocessisdelayedandhowtheoverallsystemscalabilityarenegativelyimpactedbysystemoverload.

KeywoRdSIMS, IP Multimedia Subsystem, Long Term Evolution, LTE, Modelling, Performance Evaluation, Session Initiation Protocol, SIP

INTRodUCTIoN

IPMultimediaSubsystems(IMS)(3GPP,2006)andSessionInitiationProtocol(SIP)(Rosenberg,2002)performanceplayamajorroleinmultimediacommunicationnetworksbyalteringtheKeyPerformanceIndicators(KPIs)relatedtotheQualityofExperience(QoE)metricsoftheend-to-endservice.RegistrationRequestDelay(RRD)isoneoftheSIPKPIsthatalsoinfluencebothIMSKPIsandenduserQoE.Therefore,itiscrucialtoevaluatetheperformanceofbothSIPandIMSbasedontheRRDmetricinordertogiveanindicationoftheoverallsystemcapacityandscalabilitypotential.

5Gcommunicationsisthenewtechnologythatwillintegratemultipleaccesstechnologyintooneintegratedsolutionadoptedbyallvendorsandmanufacturers.EndusersanddeviceswillbeabletocommunicateseamlesslywithfewerrestrictionsandmoreoptionscomparedtooldertechnologiesScalabilityisamongthechallengesthatlimittheexploitationofthefullcapabilitiesofthecurrenttechnologies.Manyrecentstudieshavetriedtoovercomethescalabilitychallengeassociatedwiththe5Gstandardsset.AnewintegratedsolutionwithexternalSIPapplicationthatisaccessedover


18

LTEwithdifferentvoicecodecsisintroducedinotherstudies(Haibeh&Hakem,2017).However,thesolutionproposedlacksthesupportofstandardisedadoptedsolutionsthusintroducingcomplexitiesinimplementations.InasimilarSIPperformanceevaluationanenhancementtrial(Subramanian&Dutta,2009),transactionstatesoftheSIPserverarecharacterisedtomodeltheperformanceoftheserver.InthetrailM/M/cqueuingmodelwasusedalongwithabenchmarkingperformanceindicatorthat reflects system performance. The trial showed that the multi-threaded architecture utilisingparallelprocessingofSIPmessagesprovidesamorescalableandefficientsolutionforlargernumberofclients.However,thestudywasbasedonsimpleSIPserversthatdonotreflectmorecomplicatedprocessingrequiredbymultimediaservicesthattendtousemorethanoneSIPserver.

Anotherstudy(Ono&Schulzrinne,2008)usedtheStreamControlTransmissionProtocol(SCTP)asatransportprotocolforSIPmessagesinsteadofTCPandUDP.TheimplicationsofusingdifferenttransportprotocoloverSIPscalabilityandperformanceispresentedanditisshownthatSCTPhasanegativeimplicationoverSIPscalabilityduetotheaddedoverhead.Otherresearch(Yavas,Hokelek,&Gunsel,2016)hasfocusedontheschedulingmechanismstopreventSIPsystemoverloadandtoincreaseitsscalability,theproposedsolutionusesapriority-basedmechanismtodynamicallyestimatethebehaviouroftheserverandprovideamorescalablesolutioncomparedtotheconventionalSIPservers.Again,thisstudyevaluatesonesingleSIPserver.

Thispaperanalyseshowoverallsystemcapacityandscalabilityisaffectedbyadditionaltrafficgeneratedwhenmoreuserstrytoaccessthesystemsservices.Thiscouldhappeninamissioncriticalcommunicationsystemduringnaturaldisasterorlarge-scaleattack,resultinginasuddenincreaseinthenumberofusers.

Itwasfoundthat,withinlimits,thesystem’sabilitytoprocesstheregistrationrequestspertimeunitincreasesexponentiallywhenthenumberofusersisincreased.Oncethelimitisreachedhowever,thenumberofprocessedrequestsstartstodecreaseandeventuallydegradeleadingtosystemfailure.Thesimulationresultsshowthatthesystemwasabletohandleamaximumof7,400registrationspersecond,aworkloadthatcouldoccurduringanationwidedisasterwithmanyuserstryingtoaccesstheMissionCriticalSystem(MCS).

TheneedforamoredetailedstudyofotherSIPandIMSKPIstoprovideabetterunderstandingoftheoverallsystemperformanceisthusclear.Thestudywillenablefurtherprogresstowardssystemperformanceenhancementandoptimizationinordertoavoidsinglepointoffailureofthesystem.

ReSeARCH MeTHodoLoGy

Apreviouslydevelopedresearchmethodology(Creswell,2009)wasfollowedforboththequalitativeandquantitativeapproacheswhensettingtheparametersforallmeasurementsandsimulations.Themethodologyfordecidingthequalitativevaluesthatneedtobeinvestigatedcanbesummarizedasfollows:

1. Determinethechallengesthatneedtobeinvestigatedwithinthescopeofthestudy.Whiletheprojectembedsseveralchallenges, thefocuswasplacedonthesignallingdomainespeciallybetweentheenduserandthecorenetworkandthesignallinginterfacebetweenthecorenetworkandIMS.

2. DeterminethebenchmarkforwhatisconsideredacceptableSIPperformanceanddecideonthemetricsthatwillbemeasuredandusedtojudgeandcomparetheperformanceofsetup.

3. Decidetheappropriatesimulationtoolstogeneratetheresultsfrommultiplesourcesthatmeettheappropriatecomparisoncriteriabasedontheselectedtool.

4. Determine the key factors that affect the SIP signalling, in addition to multimedia servicesoperationinLTEandIMSthataffecttheoverallQoSfortheMissionCriticalsystem.


19

TheQuantitativeMethodologytoacquiretheneededmeasurementsissummarizedasfollows:

1. Developatest-bedfortheIMStodeterminetheperformanceofthesystem.Thendecidetheperformance metrics that need to be measured in order to facilitate comparison with otherimplementationsandscenarios.

2. Develop a virtual machine to generate virtual clients along with IMS in order to facilitatecomparisonbetweentheperformanceofthesystemwiththerealrunningtest-bed.

3. DevelopasimulationprojectforbothLTEandIMSoverOPNETtobenchmarktheirperformanceagainstthetest-bedimplementationperformancemetrics.

4. Determinethevariables,models,scenariosandparametersinOPNETthatneedtobeadjustedandanalysedtoenableoverallsystem’sperformanceevaluation.

Insummary,asshowninfigure1,therearethreesimulation/testingoptions.Thissectionpresentsthetest-bedsandsimulationresultsthatrelatedtotheproject.First,IMS

test-bedscenarioandresultsaregiven.Secondly,theOPNETsimulationscenariosandresultsaredemonstrated.Thirdly,thelimitationsandchallengesofbothexperimentsarediscussed.

TeST-Bed eXPeRIMeNT

Figure2showstheexperimentaltopologyofthetest-bed.Thetest-bediscomposedoffourmainparts: thePacketGenerator; IMScorewhich isbasedonOpen-IMS-Coremodel (Fokus,2004);PacketAnalyser,andDomainNameServer(DNS).Thepartsfunctionandoperationareasfollows:

• PacketGenerator:Thepacketgeneratorisresponsibleforsimulatingvirtualclientsthatthengenerateconcurrentcallsthataretransmittedinaserialorparallelmannerbyatheoreticallyunlimitednumberofusers.DuetothefocusonSIPandIMSperformance,thePacketGeneratorisdesignedtosendSIPRegisterMessage(asdefinedbyRFC3261)inadditiontoSIPinviteandbyemessages.AllthemessagesaretransportedusingtheUDPwherethesenderportaddressisdynamicallyallocatedsoastoavoidusingrestrictedportsatthesenderorserversides.TheGUIinterfaceofthePacketGeneratorenablestheusertoselectapredefinedsetofusersandtheProxyIPaddress.Finally,theSIPrequest-sendingpatternisselectedtobeeitherserialorparallel.

• IMSNetwork:TheIMScoreisbasedonOpen-IMS-Core(Fokus,2004)developedbytheFOKUSInstituteforOpenCommunicationSystem.TheserverembedtheIMSCallSessionControlFunctionsCSCFs;suchasPCSCF,I-CSCF,andS-CSCF,inadditiontothehomeSubscriber

Figure 1. Available simulation and testing tools


20

StationHSS.Allareconsideredpartofthecorearchitectureforthenextgenerationofnetworksasspecifiedby3GPP.ThepurposeoftheexperimentistotestthecapacityoftheIMSintermsofthemaximumnumberofusersthatcanbeadoptedbythesystemwithoutcausingstabilityissues.

• PacketAnalyser:ThepacketssentbythePacketGeneratoraremonitoredusingWiresharkasapacketanalyseratthesenderside.ThetracefilesextractedfromthepacketanalyzerhelpincalculatingtheKPIvaluesforbothSIPandIMS.

• DNS:anexternalDomainNameServer(DNS)toresolvetheIPaddressesofallserversinthesystemsetup.

BasedontheprevioussetuptheexperimentaimedtoevaluatetheSIPperformanceovertheIMSusingeitherawiredorawirelessconnectivitywiththeserver.Forthispurpose,theregistermessagedelaywascalculatedbyrunningWiresharkatthepacketgeneratorsideandcalculatingthedifferencebetweenthesentregistrationrequesttimeandthe2.00OKresponsereceptiontime.ThedatawasthenexportedusingMATLABandanalysedtheProbabilityDensityFunction(PDF)andCumulativeDensityFunction(CDF)curvescalculated.TheseprovideabetterunderstandingofthevarianceinRegistrationdelaywithinthesamescenarioandamongdifferentrunningscenarios.

Figure3showstheGUIinterfaceforthePacketGenerator.Theuserfirstselectsapredefinedsetofusers’databasesandtheProxyIPaddress(whichistheIMSserverIP).Inaddition,thedomainnameisinsertedandtheSIPrequestsendingpatternselected(eitherseriesorparallel).PressingREGISTERinitiatesthesendingoftheregistrationrequests(oneperuser)consecutivelyanddynamically.ThepacketssentbythePacketGeneratoraremonitoredusingWiresharkatthesendersidewhilethelog

Figure 2. Experiment test-bed


21

screenatthepacketgeneratorrecordsthetimestampofthesentrequestsandreceivedresponses,whichhelpsincalculatingtheend-to-endapplicationdelay(thetimebetweenpeerapplicationlayers).

Basedontheprevioussetup,theexperimentaimedtoevaluatetheSIPperformanceovertheIMSusingeitherwiredorwirelessconnectivitytotheserver.Forthispurpose,theregistermessagedelayiscalculatedbyrunningWiresharkatthepacketgeneratorsideandcalculatingthedifferencebetweenthesentregistrationrequesttimeandthe2,00OKresponsereceptiontime.Thedataisthen,usingMATLAB,exportedandmanipulatedinordertogeneratecurvesforabetterindicationofthevarianceinRegistrationdelaywithtime.Theexperimentwasrepeatedmultipletimes,eachtimethenumberofuserswasincrementedinboththewiredandwirelessscenarios.

ReSULTS

Inthisscenario,thepacketgeneratorwaswireddirectlytotherouterandthenumberofuserssendingtheregistrationrequestwereincrementedinstepsof200intherangefrom100to1,300users.Figure4showsthePDFandCDFoftheregistrationdelayfor100whileFigure5showsthePDFandCDFfor500users.

Figure 3. Packet generator GUI


22

Figure 4. CDF and Density functions of the Registration delay for 100 users

Figure 5. CDF and Density functions of the Registration delay for 500 users


23

Fromfigures4and5, it isclear that theregistrationdelayfor500usersmore thandoubledcomparedtothatachievedfor100users,andincreasedevenfurtherwhenincreasingthenumberofusersineachstep.Similarly,sevenvaryingscenarioswereimplementedusingthetest-bed.Inthefirstscenario,100userregistrationrequestsweretransmitted,whileinthesubsequentscenariosthenumberofuserswasincrementedinstepsof200until1,300userswereconsideredintheseventhscenario.Totestthescalabilityofthesystem,thenumberofuserswasgraduallyincreasedinordertogainabetterunderstandingoftherelationbetweenthenumberofusersandtheKPIvaluesforbothSIPandIMS.

Figure 6 shows the Probability Distribution Function (PDF) and figure 7 the CumulativeDistributionFunction(CDF)fortheRRDofthefirstscenariowithonly100userseachsendingoneregistrationrequestatatimeinsequentialorder.Asshowninfigure7,90%ofRegistrationrequestsneedlessthan40mstobecompletedwhichmeetstherequirementsofmissioncriticalapplicationsandreal-timeservices.Asshowninfigure6,thehighestfrequencyoftheregistrationtrialsneedsonaverage20mstobecompleted.Thisisconsideredthebest-casescenarioandwasusedasabenchmarkfortheotherscenariosinordertoenablecomparisonofboththeRRDtimeandthepercentageoftrialsthatfinishatcertaintimethreshold.

Similarly,thePDFsandCDFsforallsevenscenariosweregeneratedasshowninfigure8and9.It isclear thatwhenthenumberofclients increases, thesystemneedsmoretimetoservetheregistration requests.Thishappensdue toaccumulationofbothSIPandDIAMETERsignallingmessagesinthequeuesoftheCSCFsinterfaces(especiallyinS-CSCF)andtheHSSinterface.BothS-CSCFandHSSareconsideredbottleneckpointsofcongestionthatareaffectedsignificantlyasthenumberofregistrationrequestsincrease.Thisleadstoaqueuingdelaythatemergesrapidlyinthesysteminterfaces,whichcaneventuallycausesystemfailure.

Twoperformancemetricswereusedtofacilitatecomparisonofthesevenscenarios.Thefirstwasthetimeneededtoprocesssuccessfully90percentofrequests,referredtoas90%completiontime(90CT).Whilethesecondwasthepercentageofsuccessfullycompletedregistrationrequestswithin40msseconds(whichisthemaximumRRDtimeneededtoprocess90%ofrequestsinthe100-usersscenario),referredtoas40msCompletionRatio(40msCR).

Figure 6. PDF of RRD for 100 users


24

Figure 7. CDF of RRD for 100 users

Figure 8. PDF of RRD values for all scenarios


25

Table1showstheaverageRRDvaluesalongwith90CTand40msCRforeachscenarioandtheregistrationrequestspersecond(RRps)processingrate(whichisthenumberofregistrationrequeststhataresuccessfullyprocessedbythetest-bedperunittime).TheRRpsvaluesreplicatearealworlddisasterscenario,wherethousandsofusersmaysendregistrationrequesttogainaccesstothesystem-whichissupposedtobescalableandreliable-atthesametime.

Basedontheresults,itcanbeseenthattheRRpsincreasesexponentiallyasthenumberofusersincreasesuptoalimit(of1,100users)beforebeginningtodecrease,leadingeventuallytosystemdegradationandfailure.ThisisshownclearlybyRRpsforbothscenarios6and7,wheretheRRpsofscenario7ismuchlessthantheRRpsforscenario6althoughthenumberofusershasincreasedby200.

Asexpected,the90CTincreasesasthenumberofusersrises,startingfrom40msforscenario1throughto150msforscenario7.Thisistobeexpectedduetotheincreasedprocessingtimeneededfortheadditionalreceivedregistrationrequest.Moreover,itwasfoundthatthe40msCRdecreaseswithanincreasednumberofusers.Comparingthevalueswithscenario1(thebenchmark)showsthatonly15%ofregistrationrequestsneededlessthan40msRRDvaluetobecompleted,whichagainimpliesthatthesystemisnotabletoprocessthereceivedrequestwithinverystricttimelimit.

Figure 9. CDF of RRD values for all scenarios


26

oPNeT SIMULATIoN

TofacilitateinvestigationoftheLTEsystem,especiallytheSIPsignallingperformanceoverLTEcommunicationnetwork,theOPNETsimulatorwasusedtocreateascenariowithmultipleusersinitiatingcalls.ThisenabledtheSIPperformancemetricstobeusedtomeasuretheefficiencyofthesystemanditscapacitytolerance.Figure10showsthecreatedsetup.

Simulation Setup and ScenariosIn this researchstudy,OPNETModellerprovides therequired levelofsimulationcapabilities toimplement and model different multimedia applications over LTE. The system design that wasimplementedandinvestigatedisshowninfigure10andisbasedontheconfigurationparametersshowninTable2.TheimplementationoftheLTEnetworksystemisbasedonasingleEvolvedPacketCore(EPC)thatservestwoeNBs,eachwithfourclients.TheclientsineNB1makeSIP-basedVoIPcallstotheclientsineNB2throughtheEPCinaNormaldistributioncallgenerationsystem,usingafixed-lengthcall.TheEPCisthenconnectedtotheSIPserver,whichreflectstheperformanceoftheP-CSCFintheIMS,thatmanagetheregistration,callinitiationandcallterminationprocessesusingtheSIPsignalingsystemusingtheIPcloud.Inthisreseach,thesimulationswereperformedwithoutanybackgroundtrafficintheLTEsystemandtheIPnetwork.ThisenablesustostudytheactualperformancelevelforSIP-basedVoIPapplicationswithinabesteffortenvironmentwhichhelpswiththeresultsaccuracy.Itshouldbenotedthatthisresearchhasnotconsideredanyclientsmobilityperformanceimplicationoversignallingdelays,itisleftasafutureworktodiscussitfurther.

Thesimulationimplementationshasconsideredfourscenariosbasedonthedesignshowninfigure10andthesimulationparametersshowninTable2.ThefirstscenariorepresentsthebasicimplementationforVoIPapplicationsoverLTEusingasinglepairofUEsbetweenclientA-1ineNB1andclientB-1ineNB2.Thisscenarioexaminesthebest-caseimplementationoftheassignednetworksystemwithonlyonesinglecallatatime.ThesecondscenariohasanadditionalconnectionwithmultiplecallswithanotherpairofUEs(clientA-2andclientB-2)addedtothefirstscenario.Asimilarthingistrueofthethirdscenario,whereadditionalpairsofcallsareadded(clientA-3andclientB-3).Finally,thefourthscenariohasyetanotheradditionalpairbetweenclientA-4andB-4.ThisgradualincreaseinthepairsofSIP-basedVoIPcallsallowedtheperformanceoftheSIPsignallingsystemoverLTEbasedcommunicationswithadditionalVoIPcallsbetweendifferentclientstobechecked.ThehighestloadofVoIPcallsisrepresentedinthefourthscenariothatconsumeshigherbandwidthoverLTEwhereallclientsineacheNBarecallingonesingleclientintheothereNB.Therefore,theresultsoftheseimplementedscenarioscanbecomparedandstudiedthroughouttheresearchstudyintermsoftheperformanceforSIPsignallingandefficiencyforLTEsystem.

Table 1. Calls statistics from simulation results

Scenario no. RRps RRD Avg. Value

90CT (ms) 40msCR (%)

Scenario1(100users) 1,800 20 40 100%

Scenario2(300users) 3,600 28 47 80%

Scenario3(500users) 5,900 44 65 40%

Scenario4(700users) 4,900 22 55 73%

Scenario5(900users) 5,500 64 105 23%

Scenario6(1100users) 7,400 77 125 17%

Scenario7(1300users) 5,800 88 150 15%


27

Simulation ResultsAsthemainconsiderationsinthisstudyareSIPsignallingandLTEperformanceformissioncritical

systems, the results focus on the call setup time and the related LTE performance metrics. Theoptimumnumberofinitiatedcallsforeachpairofcallsfallsbetween150and180for30minutesofsimulationtimewithauniformbaseddistributionsystemforcallsinitiation.Table3showsthenumberofrejectedcallsintheoverallsystemforthefourscenarioswiththeimplementednormalbasedsystem.Thenumberofrejectedcallshasincreasedwiththeincreasednumberofinitiatedcallpairs.ForcallsimplementedfromCallerA-1,thenumberoffailedcallsinitiationprocesseshadbeenincreasedwiththeincreasednumberofcallpairswithscenariosS2,S3,andS4,wherethetotalinitiatedcallsoverallscenariosis56.ThisincreasedfailrateduringthecallinitiationstageismainlyrelatedtotheinferiorprocessingperformanceoftheSIPservers’andLTEsystemperformance.

Table 2. Simulation parameters in OPNET

A. LTE Network System

NumberofSimulations 4 SimulationSeedNumber 128

SimulationDuration: 30Minutes=1800Seconds

NumberofEPC: 1 BackgroundTraffic 0%

NumberofeNB: 2 NumberofnodesforeacheNB: 4

AntennaGainforeNB: 15dBi eNBMaximumTransmissionPower:

0.5W

eNBReceiverSensitivity: -200dBm eNBSelectionThreshold: -110dBm

B.Applications:SIPBasedVoIP

VoIPCalls(Unlimited)

CallDuration Caller Callee

10Sec NodeA NodeB

MaximumSimultaneousCalls

SIPServer UserAgent(Caller/Callee)

VoiceCodec:

UnlimitedCall/Second 1callattimebetweeneachpair

GSM13Kbps

CallsStartTimeOffset: Normal(150sec,100sec)

CallsInter-repetitionTime: Normal(20sec,5sec)

Figure 10. System design and implementation for SIP-based VoIP applications over LTE network system in OPNET


28

Call Setup PerformanceThepurposeofstudyingthecallsetuptimeistofacilitateanalysisoftheSIPsignallingperformanceduringthemainSIPsignallingstageoverdifferentcallsessions.AslongasthecallsetuptimeforthemajorityofinitiatedSIP-basedcallswereintheacceptablerange,theperformanceoftheSIPsignallingsystemfallsinitsacceptablelevel(D.Malas,2011)(Voznak&Rozhon,2010).Figure11representstheaveragecallsetuptimeforallsuccessfulVoIPcallsforthefourimplementedscenarios.

Theresultsshowthatthescenariowithonlyonepairofcallshadthelowestaveragecallsetupwith times ranging frombetween46and47ms, and increasedup to48.5mswhen the scenarioinvolvedtwopairs.WiththreepairsofVoIPcalls,theaveragecallsetuptimeincreasedfrom47msto49.5ms.ThelongestcallsetuptimeregisteredwasforthefourthscenarioinwhichfourpairsofVoIPconnectionswereactiveatthesametime.ThesesimultaneouscallsaffectedtheSIPsignallingperformanceandincreasedtheaveragedelaybyupto50.5ms.Ingeneral,thecallsetuptimeforsuccessfully initiatedcallsover all scenarios is still at anacceptable levelwhenconsidering theperformanceoftheSIPsignallingsystem.ThiswasduetoimplementingtheLTEnetworksystemwithouthavingextraoverloadsduetoaddedbackgroundtraffic.

Table 3. Calls statistics from simulation results

SIP calls statistics for the Implemented Scenarios

Scenario S1: 1Pair

S2: 2Pairs

S3: 3Pairs

S4: 4Pairs

NumberofCallsRejectedintheoverallsystem 45 95 152 218

NumberofCallsInitiatedfromCallerA-1 56 56 56 56

NumberoffailedcallsinitiationforcallsfromCallerA-1 27 30 38 34

Figure 11. Call setup delay


29

LTE Downlink Packets DroppedTheLTEparametersoftheimplementedsystemhaveadirecteffectontheperformanceoftherunningapplications.Real-timeapplicationscanbeenhancediftheLTEsystemperformancebehaviourhasbeenconsidered.Theaveragenumberofpacketsdroppedstartsbetween1and3packets/secforthesinglepairscenarioandincreasestobetween6and18packets/secforthefourpairsscenarioasshowninFigure12.ThedownlinkpacketsdroppedofLTEsystemhasadirectlinktosuccessfulrateoftheSIPsessionsinwhichitisdirectlyproportionallyincreasing.

TheLTEsystemdelaysinthetransferreddatabetweenLTEcomponentsaffecttheperformanceforreal-timeapplications.TheaverageLTEdelayswithoneandtwopairsofVoIPcallsisbetween2msand2.7ms,asshowninFigure13.TheaverageLTEdelaysforthreepairsofVoIPcallsisfrom2.4msto3.5ms,andbetween2.5msand4.3mswithfourpairsofcalls.Thelongestdelaysmostlyoccuratthesystemstart-uptimeandstabiliselaterduringthesimulationtime.

CoNCLUSIoN

Based on the test-bed results, it has been shown that the scalability of the system is negativelyaffectedbytheincreasingnumberofregistrationrequestssenttothesystem.ItwasfoundtheRRpsincreasesexponentiallywhenthenumberofusersisincreased(uptoalimit1,100users)beforetheRRpsstartstodecreaseleadingeventuallytosystemdegradationandfailure.ThisisclearlyshownbyRRpsforbothscenarios6and7,wheretheRRpsofscenario7ismuchlessthantheRRpsforscenario6(althoughthenumberofusersincreasedby200users).

Basedonthesimulationresults,itisclearthatthereisincreasingdelayinthecallsetuptimewhentheLTEcommunicationsystemisused.Thisdelayincreasesasthenumberofservedclientalsoincreases,whichindicatesthattheDelayrequirementorthemaximumnumberofusersthatcanbeservedata timemaynotmeet themissioncriticalservicerequirements.Hence, theneedfordecreasingthegapofcallsetupdelayforcommercialbroadbandsystemscomparedwithotherdedicatedmission-criticalcommunicationssystemsisofgreatimportanceandconsideredoneofthemainchallengesformission-criticalcommunications.Thismeansthatthereisaneedforanew

Figure 12. Average packets dropped


30

mechanismthatminmisesaccessdelayoverheadbyexploringtheLTEandIMSdomainsinadditiontotheinterfacesbetweenLTEandIMSandtheinterfacebetweenLTEandUserElement.

Thesimulationhasbeenimplementedusingstaticmobilenodes(thatis,thepositionsofthenodesarefixed).Hence,thereisnohandoffaddedcomplexityforthenodesmovingbetweentwocelldomains.Ifmobilityweretobeconsidered(thatdoesnotimplymovingnodesonlybutratheradynamictopology)thensupportforhandoffmechanismsbetweenthesubscriberstationsanddifferentbasestationswouldneedtobeconsidered.Therefore,further testingofdifferentcommunicationscenariosforanend-to-endconnectivityoverLTEcommunicationsystemisneeded.Forsuchdynamictopology,theneedformeasuringtheoverallperformanceofthesystemintermsofSIPsignallinganddatastreamingdelayiscrucial.

Figure 13. Average LTE delays in second for caller A-1 node


31

ReFeReNCeS

Creswell,J.W.(2009).Research Design: Qualitative, Quantitative, and Mixed Methods Approaches.SAGEPublications.

Fokus.(2004).OpenIMScore.Retrievedfromhttp://www.openimscore.org

3. GPP.(2006).IPMultimediaSubsystem(IMS),Stage2.

Haibeh,L.A.,&Hakem,N.(2017,October19-21).AnewmobileSIPproxyintegrationsolutiontoincreasescalability in 5G mobile operators. Paper presented at the 2017 IEEE 8th Annual Ubiquitous Computing,Electronics and Mobile Communication Conference (UEMCON).

Malas,D.A.M.(2011).BasicTelephonySIPEnd-to-EndPerformanceMetrics.InRequestforComments:6076:InternetEngineeringTaskForce(IETF).

Ono, K., & Schulzrinne, H. (2008, Nov. 30-Dec. 4). The Impact of SCTP on SIP Server Scalability andPerformance. Paper presented at the IEEE GLOBECOM 2008 - 2008 IEEE Global Telecommunications Conference.

Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,...Schooler,E.(2002).SIP:SessionInitiationProtocolRFC3261.

Subramanian,S.V.,&Dutta,R.(2009,November10-12).PerformanceandscalabilityofM/M/cbasedqueuingmodeloftheSIPProxyServer-apracticalapproach.Paper presented at the2009 Australasian Telecommunication Networks and Applications Conference (ATNAC).doi:10.1109/ATNAC.2009.5464717

Voznak,M.,&Rozhon,J.(2010,September20-25).SIPBacktoBackUserBenchmarking.Paper presented at the 2010 6th International Conference on Wireless and Mobile Communications.

Yavas,D.Y.,Hokelek,I.,&Gunsel,B.(2016,November1-3).AnalyticalModelofPriorityBasedRequestSchedulingMechanismPreventingSIPServerOverload.Paper presented at the MILCOM 2016 - 2016 IEEE Military Communications Conference.

http://www.openimscore.org

http://dx.doi.org/10.1109/ATNAC.2009.5464717

Scalability and Performance Analysis of SIP based Multimedia … ·...

Documents

Transcript of Scalability and Performance Analysis of SIP based Multimedia … ·...