1 UVOD Medtem ko IMS (IP Multimedia Subsystem) [1] podrobno definira arhitekturo za transportni in kontrolni sloj, nam sami standardi [2], [3] puščajo odprtih veliko vprašanj o tem, kako naj bo strukturiran aplikacijski sloj [4]. Izziv, ki se postavlja, je, kako določen nabor storitev in uporabnikov postaviti na RCS (Rich Communication Suite) [5] aplikacijske strežnike tako, da bo to najbolj optimalno. Da bi to lahko zagotovili, je treba primerjati in ovrednotiti posamezne konfiguracije in scenarije med seboj. Še pred tem pa je treba definirati parametre, s katerimi lahko opišemo konfiguracije. Podani izziv je obdelan v dveh člankih. V prvem članku bomo definirali parametre za opis in primerjavo poljubne konfiguracije in scenarijev obnašanja ne glede ne tip storitve, naj bo na govoru temelječa ali RCS. Pri pripravi definicije parametrov za opis bomo izhajali iz analize petih storitev, ki jih postavimo na tri aplikacijske strežnike in ovrednotimo na štirih različnih konfiguracijah. V drugem članku bo sledila analiza vpliva posameznih storitev na promet strežnikov. Dodatno bomo na podlagi podanih parametrov in kriterijske funkcije naredili medsebojno primerjavo konfiguracij. Dosedanje delo je v osnovi izhajalo iz raziskovanja storitvenega posrednika (Service Broker) oziroma SCIM (Service Capability Interaction Manager), ki skrbi za interakcije na storitvenem sloju [6]. V [7] predlagajo splošen pristop k interakcijami med storitvami. Proženje analizirajo tudi v [8] in [9], kjer podajo predloge za izboljšanje zakasnitev pri osnovnem klicu. V [8] je predlagan distribuiran SCIM (DSCIM), s katerim se skrajša čas vzpostavitve seje pri veriženju. Analize in simulacije v [9] in [10] kažejo, da je S-CSCF (Serving-Call Session Control Function) največje ozko grlo za promet konfiguracije in da število aplikacijskih Prejet 8. junij, 2012 Odobren 12. september, 2012 http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem 100 GRAŠIČ, KOS strežnikov v verigi ter promet uporabnikov vplivata na to ozko grlo. V [11] so bile narejene meritve realnega prometa osnovnega klica pri enem aplikacijskem strežniku, v [12] analizirane možnosti strukturiranja konfiguracij ter v [13] narejena simulacija obnašanja za eno izmed konfiguracij. V našem primeru analiziramo večji nabor parametrov in naredimo simulacije obnašanja za več primerov. Za protokol SIP (Session Initiation Protocol) so časovne performančne metrike definirane v RFC 6076 [14]. Na tej podlagi so definirane tudi infrastrukturne metrike SIP [15]. V [16], [17], [18] so definirane časovne in druge performančne metrike za primer IMS/NGN (Next Generation Network) in IMS/PES (PSTN/ISDN Emulation Sub-system). Te časovne metrike (parametre) smo razširili ter dodali prometne in druge parametre za analizo konfiguracij. V [19] je na podlagi analize 20 različnih sej in šestih scenarijev usmerjanja definiran IMS prometni model za posamezne strežnike. V [20] sta predlagana dva modela za modeliranje prometa, to sta Poisson (brez izbruhov) in Pareto (z izbruhi). V [21] je narejena analiza signalov in prometa s stališča povezovanja do HSS (Home Subscriber Server) s protokolom Diameter. V našem primeru se ne ukvarjamo z omrežjem, ampak z aplikacijskim slojem. Ne postavljamo prometnega modela, temveč definiramo parametre, s katerimi lahko opišemo neko konfiguracijo in s katerimi bo mogoče postaviti model tudi za storitve. V [22] je opisan primer okolja za storitev prisotnosti, ki kombinira informacije o prisotnosti iz različnih virov in za različne uporabnike. V analizi storitve prisotnosti v [23] predlagajo tri dopolnitve za izboljšanje skalabilnosti in kakovosti ter v [24] ugotavljajo, da NOTIFY povzroča največji del prometa, za kar predlagajo model sistema virov. V [25] so za storitev prisotnosti analizirani primeri za logiranje, spremembe statusa uporabnika, osveževanje uporabnika ter postavljen matematični model za obnašanje tekom dneva. V našem primeru kombiniramo analizo storitve prisotnosti še s storitvijo neposrednega sporočanja in s storitvami, ki temeljijo na govoru. V to analizo uvajamo parametre za opis konfiguracij, ki bodo v pomoč pri medsebojni primerjavi konfiguracij. 2 STRUKTURIRANJE APLIKACIJSKEGA SLOJA ZA RCS Za dosedanja omrežja, ki so bila vertikalno integrirana in ki so temeljila na signalizaciji SS7 (Signalling System No. 7) in IN (Intelligent Network), je bilo značilno, da so bila zaprta, telekomunikacijske storitve v takih omrežjih so bile centralizirane in enodimenzionalne in so temeljile na govornem klicu in storitvah okoli njega. Zdaj smo prešli v horizontalno strukturirana omrežja. Slika 1 prikazuje ti dve realnosti. Govorimo o jedrnem omrežju IMS in storitveni platformi SDP (Service Delivery Platform). Nove storitve so neposredno sporočanje (IM, Instant Messaging), pošiljanje kratkih (SMS, Short Message Service) in multimedijskih (MMS, Multimedia Messaging Service) sporočil, storitve prisotnosti in lokacije, internetna televizija (IPTV, Internet Protocol TeleVision), hibridne storitve (Mashup), storitve klicanja (C2D, Click to Dial), različne Web 2.0 aplikacije, igre, delitev videa (Video Sharing), delitev vsebine (Content Sharing), pa tudi storitve, kot je SaaS (Software As A Service). Slika 1: Včerajšnja in današnja realnost – iz vertikalnih (ena storitev) v horizontalna omrežja (več storitev) 2.1 RCS RCS [5] je pobuda industrije, katere fokus je na uporabi IMS za zagotavljanje storitev mobilnim telefonskim aparatom. To pomeni uporabo ne samo govora in kontrole klica, ampak tudi možnost uporabe novih RCS- storitev, kot so neposredno sporočanje, osebni imenik in storitev prisotnosti. Večina zmožnosti RCS je sicer že na voljo pri ponudnikih internetnih storitev. RCS pouporablja zmožnosti omrežja IMS in standardno storitveno platformo IMS. 2.2 Proženje storitev na aplikacijske strežnike Na sloju storitev je v IMS definiran samo način proženja storitev, ki temelji na začetnih kriterijih filtriranja iFC (Initial Filter Criteria) [1], [3]. Le-ti so shranjeni v bazi UPSF (User Profile Server Function) (HSS). S pomočjo kriterijev filtriranja iFC se vsako prejeto sporočilo na S-CSCF razčleni in usmeri na natančno določen aplikacijski strežnik, ki se nahaja zunaj jedra omrežja in kjer se nato izvede storitev. Pri storitvah, ki temeljijo na govoru in videu, se strežnik imenuje TAS (Telephony Application Server) in je v skladu s standardom TS 22.173 [26]. Lahko pa je to strežnik, ki je v skladu z definicijo za RCS [5]. 3 PARAMETRI ZA OPIS IN MEDSEBOJNO PRIMERJAVO KONFIGURACIJ 3.1 Dileme strukturiranja aplikacijskega sloja Standardi za RCS in IMS ne definirajo niti pravil za strukturiranje aplikacijskega sloja niti pravil, kako določene konfiguracije primerjati med seboj. Prav tako ne definirajo pravil, katere parametere ali metrike pri tem uporabiti oziroma kako določiti, katera konfiguracija je najoptimalnejša. Prva dilema v zvezi s strukturiranjem je povezana z vprašanjem storitev, saj se na splošno na določenem Vertikalna omrežja Horizontalna omrežja Storitve, vsebina Storitvene zmožnosti Omrežje, transport V o IP M o b il n o P S T N STRUKTURIRANJE STORITEV RCS NA APLIKACIJSKEM SLOJU IMS - 1. DEL: PARAMETRI ZA OPIS IN MEDSEBOJNO… 101 aplikacijskem strežniku lahko nahaja ena, več ali vse storitve za določeno konfiguracijo. Tudi obnašanje storitev je drugačno kot v svetu TDM, saj ni več povezano samo z osnovnim klicem. Druga dilema je povezana z vprašanjem uporabnikov, saj imamo lahko na aplikacijskem strežniku samo del uporabnikov ali vse uporabnike. Dodatna dilema je povezana z dejstvom, da se navade uporabnikov s časom spreminjajo, primer bi bilo povečanje uporabe RCS storitev z 20 % na 30 % vseh uporabnikov. Dilema je, kaj to pomeni za določeno konfiguracijo in scenarije obnašanja, kako in v kakšnem obsegu to vpliva. Lahko se zgodi, da je v nekem trenutku najoptimalnejša neka konfiguracija, s časom, ko se spremenijo navade določenega dela uporabnikov, pa druga konfuguracija. Omenjene izzive smo razdelali v tem prispevku. Izziv, ki ga rešujemo, je, kako določiti, katera konfiguracija je v nekem trenutku najboljša oziroma katere izmed konfiguracij so manj primerne za določeno obnašanje in navade uporabnikov. Izziv je, kako zastaviti medsebojno primerjavo in evalvacijo ter katere parametre pri tem uporabiti. Definirali bomo parametre, ki so pomembni za opis ter za medsebojno primerjavo in evalvacijo konfiguracij in scenarijev. Izhajali bomo iz analize petih storitev, ki jih postavimo na testno okolje, ki vsebuje tri aplikacijske strežnike ter integriran CSCF (Call Session Control Function). Testno okolje prikazuje slika 2. 3.2 Analizirane storitve Za analizo definicije parametrov smo uporabili nabor petih govornih in negovornih storitev [1], [23]. To so storitve predstavitev številke (OIP/TIP, Originating Identification Presentation / Terminating Identification Presentation), preusmerjanja (CDIV, Communication Diversion), zvonjenja (CAT, Customized Alerting Tones), neposrednega sporočanja (IM, Instant Messaging) in prisotnosti (Presence). Poleg analize samih storitev je treba upoštevati še registracijo naročnika in naročanje naročnika na določeno storitev. Tabela 1: Razvrščanje analiziranih storitev Storitev TAS osnovni TAS plus TAS RCS IM RCS P RCS OIP/TIP - - - - CAT - - - - CDIV - - - - IM - - - - Prisotnost - - - - Treba je upoštevati tudi izvajanje več storitev hkrati. Pri storitvah, ki so povezane z govornim klicem, lahko na poti INVITE prihaja do veriženja. Storitev se npr. izvede najprej na prvem aplikacijskem strežniku (npr. OIP za uporabnika A), nato na drugem aplikacijskem strežniku (npr. TIP za uporabnika B), nato na tretjem aplikacijskem strežniku (npr. storitev CDIV za uporabnika B) in tako naprej. To seveda na strežnike vnaša zakasnitev in tudi dodaten promet. 3.3 Razvrščanje storitev in uporabnikov za izbrane konfiguracije Kombinacij za razvrščanje storitev je veliko. Izbrali smo najosnovnejšo možnost, da smo storitve razvrščali po izvoru storitve, TAS posebej (TAS osnovni, TAS plus, TAS) in RCS posebej (RCS IM, RCS Prisotnost, RCS). Tabela 1 prikazuje način razvrščanja v skupine. Slika 2: Shema analiziranega okolja Pri uporabnikih, ki jih je N, smo razdelitev naredili tako, da se uporabniki nahajajo na vseh aplikacijskih strežnikih, na vsakem samo tretjina (N=1/3) ali polovica (N=1/2). Tabela 2: Razvrščanje storitev in uporabnikov za izbrane konfiguracije K Ime konf. AS1 AS2 AS3 K0 TDM - - - K1 AS vse 3x TAS, RCS N=1/3 TAS, RCS N=1/3 TAS, RCS N=1/3 K2 RCS IM&P TAS RCS-IM RCS-P K3 TAS plus TAS osnovni TAS plus RCS K4 TAS 2x TAS N=1/2 TAS N=1/2 RCS Iz nabora konfiguracij smo izbrali štiri (K1, K2, K3, K4), ki so predstavljene v tabeli 2. Konfiguracije so najosnovnejše možnosti strukturiranja aplikacijskega sloja RCS glede na razdelitve storitev in naročnikov. Na aplikacijskem strežniku se izvajajo vse storitve (K1), samo TAS storitve ali samo RCS storitve (K2, K3, K4). Storitve se izvajajo za vse uporabnike (K2, K3) ali samo za del uporabnikov (K1, K4). Konfiguracija K0 je namenjena za primerjavo, ko se vse storitve izvajajo na S-CSCF. 3.4 Parametri za opis Definirali smo parametre, ki so pomembni za opis določene konfiguracije. Po dosegljivih podatkih takšni parametri, razen določenih časovnih, še niso bili definirani. Parametri opisa se nanašajo na več različnih vidikov opisa konfiguracije in so: splošni parametri uporabnikov, časovni parametri, parametri prometa strežnikov, parametri osnovnega klica ter parametri normiranja na strežnik S-CSCF in na promet uporabnika. V tabeli 3 je podan podroben seznam vseh parametrov za opis konfiguracij. AS1 UE-1 UE-N UPSF S/P/I-CSCF AS2 AS3 UE-2 UE-3 102 GRAŠIČ, KOS 3.4.1 Predpostavke pri definiciji parametrov Pri definiciji parametrov za opis konfiguracij izhajamo iz nekaterih predpostavk, in sicer:  aplikacijski strežniki lahko podpirajo vse storitve,  pri splošnem govoru o RCS storitvah so mišljene RCS in TAS storitve,  vsa izvajanja, predpostavke in definicije se nanašajo na glavno prometno uro,  vse definicije se nanašajo na signalni promet s stališča S-CSCF in aplikacijskih strežnikov,  signalni promet je opisan kot število signalov ali kot promet (vhodni, izhodni ali kot vsota),  v našem primeru za promet privzamemo število signalov (vsota signalov). 3.4.2 Splošni parameteri uporabnikov Splošni parametri uporabnikov so namenjeni za opis uporabnikov in njihovih lastnosti. Z omenjenimi parametri lahko določimo promet, ki ga generirajo uporabniki. Frekvenco (F) in število signalov (S) je treba določiti za vsako fazo seje posebej, kot so registracija, vzpostavitev seje, neposredno sporočanje, objavljanje stanj, izvajanje storitev in drugo. Za izračun prometa na uporabniku (TU, Traffic on User) je treba določiti vsoto vseh signalov in frekvenc sprememb za vsako izmed teh faz (F1*S1+F2*S2+..). Pri storitvah, ki temeljijo na govornem klicu, to pomeni vsoto SIP sporočil za vzpostavitev in porušitev seje (INVITE, 100, 180,..), pomnoženo s številom sej v glavni prometni uri. Podobno velja tudi za primer neposrednega sporočanja (MESSAGE, 200) in registracije (REGISTER, 401, 200). Pri storitvi prisotnosti je treba upoštevati število in frekvenco objavljanja stanj (PUBLISH, 200, NOTIFY) ter število in frekvenco sprejemanja stanj (NOTIFY, 200). Parameter delež uporabe storitev (u) določa dejansko uporabo storitve. Za storitve, ki temeljijo na govornem klicu, kot je TIP/OIP, bo u=100 %, za druge, kot je CAT, bo lahko u=20 %, oziroma za neposredno sporočanje bo lahko u=70 %. Pri storitvi prisotnosti imamo še parametra za objavljanje stanj (p) (npr. 70 %) in za sprejemanje teh stanj (w) (npr. 50 opazovalcev). 3.4.3 Časovni parametri Časovni parametri so namenjeni za ovrednotenje časovnega obnašanja določene konfiguracije. Določeni časovni parametri so definirani v [14], [17], [18]. Po RFC 6076 [14] so to parameteri SRD (Session Request Delay), SDD (Session Disconnect Delay), SDT (Session Duration Time) in RRD (Registration Request Delay). Prvi trije se nanašajo na osnovni klic, zadnji na registracijo. SRD se nanaša na čas vzpostavitve seje (med INVITE in 180, stran uporabnika A) in je ekvivalenten parametru Post Selection Delay, ki ga poznamo iz TDM sveta in je definiran v E.721 [27]. SDD je čas rušenja seje (med BYE in 200), SDT je čas seje (med 200 in BYE) ter RRD čas registracije (med REGISTER in 200). Obstoječa parametra SRD in SDD smo dopolnili še z minimalno in maksimalno vrednostjo (SRDmin, SRDmax, SDDmin in SDDmax). Informacija o minimalni in maksimalni zakasnitvi za vzpostavitev ali porušitev seje je smiselna, ker dobimo natančnejše podatke o konfiguraciji, saj je v verigi storitve lahko različno število aplikacijskih strežnikov (eden, dva, trije,..) in je zakasnitev za en nabor lahko drugačna kot za drugi nabor storitev. Definirali smo še druge časovne parametre, ki niso standardizirani, se pa na določen način uporabljajo in se nanašajo na storitve: čas za naročanje storitev (SSD, Session Subscribe Delay), čas za neposredno sporočanje (SMD, Session Messaging Delay) in čas za objavo stanja prisotnosti (SPD, Session Publish Delay). 3.4.4 Parametri prometa strežnikov Prometni parametri so namenjeni za prometno ovrednotenje strežnikov in za primerjavo prometa. Definirali smo promet za posamezni aplikacijski strežnik (TAS, Traffic on Application Server) ter povprečen promet glede na vse aplikacijske strežnike (TASavg). Definirali smo še promet na najbolj (TASmax) in najmanj obremenjenem strežniku (TASmin) ter njuno razmerje (TASmm), ki nam omogoča določiti, do katere mere so aplikacijski strežniki enakomerno obremenjeni. Določili smo še promet na vseh aplikacijskih strežnikih (TASall), promet na S-CSCF (TS) ter promet za celotno konfiguracijo (C, Configuration) (TC). 3.4.5 Parametri osnovnega klica Parametri osnovnega klica (BC, Basic Call) so namenjeni za ovrednotenje strežnikov glede na osnovne govorne klice. V svetu TDM smo imeli metrike, ki so temeljile na osnovnem govornem klicu. Osnovni govorni klic je zaradi primerjave s celotnim prometom pomemben podatek tudi na RCS. Pri TDM je bila definicija osnovnega klica preprosta. Tam je bila pot osnovnega klica enaka poti dopolnilnih storitev in je navadno potekala samo skozi eno centralo. Za RCS je drugače. Tu pod osnovni klic privzamemo tudi najosnovnejše na govoru temelječe storitve, ki se nahajajo na aplikacijskih strežnikih. V našem primeru bomo za osnovni klic vzeli osnovne skupine za TAS (TAS osnovni ali TAS). Parameteri osnovnega klica (BC) definirajo število signalov (S, Signals) osnovnega klica na uporabniku (BCSU), na S-CSCF (BCSS) ter število osnovnih klicev (C, Calls) na uporabniku (BCCU). Definirajo število osnovnih klicev na S-CSCF (BCS) in na vseh aplikacijskih strežnikih (BCASall), kjer gre klic skozi dva aplikacijska strežnika (stran uporabnika A in B). 3.4.6 Parametri normiranja na strežnik S-CSCF Parametri normiranja na strežnik S-CSCF (NS, Normed on S-CSCF) definirajo parametre glede na to, ali bi imeli v verigi samo S-CSCF, torej če imamo veriženje seje prek več aplikacijskih strežnikov v primerjavi s STRUKTURIRANJE STORITEV RCS NA APLIKACIJSKEM SLOJU IMS - 1. DEL: PARAMETRI ZA OPIS IN MEDSEBOJNO… 103 tem, če bi imeli v verigi samo S-CSCF. Parametri nam definirajo, za koliko se nam v tem primeru povečajo zakasnitve ali promet. Tabela 3: Parametri za opis Ime Splošni parametri uporabnikov F Frekvenca sprememb S Število signalov za vsako spremembo N, TU Število uporabnikov, promet na uporabniku u Delež uporabe določene storitve p, w Delež objavljanja (p) in sprejemanja (w) stanj Časovni parametri RRD Čas registracije (REGISTER do 200) SSD Čas naročanja na storitev (SUBSCRIBE do 200) SRD Čas vzpostavitve seje (INVITE do 180) (tudi SRDmin, SRDmax) SDT Čas seje (200 do BYE) SDD Čas porušitve seje (BYE do 200) (tudi SDDmin, SDDmax) SMD Čas sporočanja (MESSAGE do 200) SPD Čas objave stanj prisotnosti (PUBLISH do 200) Parametri prometa strežnikov TAS Promet za vsak posamezni AS A Število vseh AS TASavg Povprečen promet na AS (glede na vse AS) TASmax Promet na najbolj obremenjenem AS TASmin Promet na najmanj obremenjenem AS TASall Promet na vseh AS TASmm Razmerje med najbolj in najmanj obremenjenim AS (razmerje TASmax/TASmin ) TS Promet na S-CSCF TC Promet celotne konfiguracije (TS+A*TASavg) Parametri osnovnega klica BCSU Število signalov osnovnega klica na uporabniku BCSS Število signalov osnovnega klica na S-CSCF BCCU Število osnovnih klicev za uporabniku BCS Število osnovnih klicev na S-CSCF BCASall Število osnovnih klicev na vseh AS Parametri normiranja na strežnik S-CSCF (glede na to če bi imeli samo S-CSCF) NSSRD SRD na S-CSCF (dejanski SRD/SRD, če je v verigi samo S-CSCF) NSTASavg Povprečni promet na AS (razmerje TASavg/TS) NSTASmax Največji promet na AS (razmerje TASmax/TS) NSTASall Promet po vseh AS (razmerje A*TASavg/TS) Parametri normiranja na promet uporabnika NUTAS Promet na uporabnika za vsak posamezni AS (razmerje TAS/N) NUTASavg Promet na uporabnika za povprečen promet na AS (razmerje TASavg/N) NUTASmax Promet na uporabnika na najbolj obremenjenem AS (razmerje TASmax/N) NUTASmin Promet na uporabnika na najmanj obremenjenem AS (razmerje TASmin/N) NUTASall Promet na uporabnika na vseh AS (razmerje TASall/N) NUTS Promet na uporabnika za S-CSCF (razmerje TS/N) NUTC Promet na uporabnika za celotno konfiguracijo (razmerje TC/N) Parametri definirajo dejanske zakasnitve in promet glede na to, ali bi bil v verigi samo S-CSCF: zakasnitev SRD (NSSRD), povprečni promet na aplikacijskem strežniku (razmerje TASavg/TS) (NSTASavg), največji promet na aplikacijskem strežniku (razmerje TASmax/TS) (NSTASmax) in celotni promet glede na promet na S-CSCF (razmerje A*TASavg/TS) (NSTASall). 3.4.7 Parameteri normiranja na promet uporabnika Parametri normiranja na promet uporabnika (NU, Normed on User) definirajo prometne parametre glede na uporabnika. Definirajo promet na uporabnika za vsak posamezni aplikacijski strežnik (NUTAS), povprečen promet na aplikacijski strežnik (NUTASavg), promet na najbolj (NUTASmax) in najmanj (NUTASmin) obremenjenem aplikacijskem strežniku, na vseh aplikacijskih strežnikih (NUTASall), na S-CSCF (NUTS) in za celotno konfiguracijo (NUTC). 3.5 Parametri za medsebojno primerjavo Medsebojno primerjavo konfiguracije in scenarijev je nemogoče izvesti, če uporabimo vse do zdaj opisane parametre. Zato smo izmed vseh parametrov za opis izbrali parametre za medsebojno primerjavo in evalvacijo konfiguracij in različnih scenarijev. Definirali smo tri vrste parametrov: časovne, za promet strežnikov in za normiranje na promet uporabnika. Parametre za medsebojno primerjavo prikazuje tabela 4. Tabela 4: Parametri za medsebojno primerjavo Ime Časovni parametri uporabnikov SRD Čas vzpostavitve seje (INVITE do 180) SRDmax Najdaljši čas vzpostavitve seje (INVITE do 180) Parametri prometa strežnikov TS Promet na S-CSCF TASmax Promet na najbolj obremenjenem AS TASall Promet na vseh AS TASmm Razmerje najbolj in najmanj obremenjenega AS Parametri normiranja na promet uporabnika NUTS Promet na uporabnika za S-CSCF (razmerje TS/N) NUTASall Promet na uporabnika na vseh AS (razmerje TASall/N) NUTASmax Promet na uporabnika na najbolj obremenjenem AS (razmerje TASmax/N) Časovna parametra sta pomembna, ker z njima lahko ovrednotimo zakasnitve sistema. S parametri prometa strežnikov ovrednotimo promet skozi strežnike konfiguracije. Dodatno so parametri prometa primerni za analizo spremembe prometa skozi strežnike, če se nam poveča npr. uporaba storitve prisotnosti (npr. za 30 %). S parametri normiranja na promet uporabnika ovrednotimo promet na uporabnika. Dodatno so parametri normiranja na promet uporabnika primerni za analizo potrebne procesne moči za S-CSCF in aplikacijske strežnike, če le vemo, za koliko se bo povečalo število uporabnikov. Primerjanje na podlagi parametrov za primerjavo je mogoče na tri načine. Prva možnost je primerjanje po enem izmed podanih parametrov (npr. po povprečni zakasnitvi SRD). Druga možnost je primerjanje po vseh 104 GRAŠIČ, KOS parametrih za določen sklop parametrov (npr. za promet). Tretja možnost pa je primerjanje po več parametrih (npr. po vseh parametrih za primerjavo). Na podlagi rezultatov primerjanja na enega izmed načinov lahko definiramo optimalno konfiguracijo ali več optimalnih konfiguracij za enega ali več parametrov. 4 RAZPRAVA IN SKLEP V prvem od dveh člankov smo za problem, ki je povezan s strukturiranjem aplikacijskega sloja za poljubne storitve na IMS in RCS, definirali parametre za opis konfiguracij. Okoli štirideset definiranih parametrov vsebuje bistvene informacije za opis neke konfiguracije. Dodatno smo izmed vseh parametrov za opis izbrali parametre, ki so namenjeni za primerjavo in evalvacijo konfiguracij. Če standardi za RCS in IMS ne definirajo niti pravil za strukturiranje aplikacijskega sloja niti pravil, kako določene konfiguracije primerjati med seboj, so podani parametri korak k bolj sistematičnemu pristopu k strukturiranju aplikacijskega sloja. V drugem članku bomo s pomočjo podanih parametrov medsebojno primerjali konfiguracije in scenarije ter s pomočjo stroškovne funkcije določili najoptimalnejšo konfiguracijo za scenarij izvajanja. Bodoče raziskave v tej smeri bodo usmerjene v analizo konfiguracij in različnih scenarijev obnašanja za še večje število primerov, tako za primer realnega prometa kot tudi simulacij obnašanja.