1 UVOD
Izziv, ki nastaja v zvezi s strukturiranjem storitev RCS
(Rich Communication Suite) na aplikacijskem sloju
IMS (IP Multimedia Subsystem) [1], je, kako določen
nabor storitev in uporabnikov postaviti na aplikacijske
strežnike RCS tako, da bo to najbolj optimalno.
V prvem članku [2] smo predstavili parametre za
opis in medsebojno primerjavo konfiguracij za
strukturiranje storitev RCS na aplikacijskem sloju IMS.
V tem, drugem članku bomo na podlagi realnega
okolja analizirali prometne vplive petih storitev na
promet strežnikov, kar nam bo pomagalo postaviti
prometni model za postavljanje storitev na strežnike. Na
podlagi postavljenega modela bomo s pomočjo podanih
parametrov medsebojno primerjali konfiguracije za
izbrane scenarije izvajanja ter s pomočjo
optimizacijskega procesa in stroškovne funkcije, ki
temelji na obremenitvi strežnikov, podali predlog za
optimalno postavitev storitev na konfiguracijo.
2 MODEL VPLIVA STORITEV NA PROMET
STREŽNIKOV
2.1 Opis testnega okolja
Za testiranje je bilo vzpostavljeno testno okolje, kot ga
prikazuje slika 1. Sestavljajo ga podatkovna baza UPSF
(User Profile Server Function), kompaktni strežnik
CSCF (Call Session Control Function) (C-IMS,
Compact-IMS), ki izvaja funkcije P-CSCF (Proxy-
CSCF), I-CSCF (Interrogating-CSCF) ter S-CSCF
(Serving-CSCF), trije aplikacijski strežniki (AS1, AS2,
AS3), strežnik prisotnosti (PS, Presence Server) in
uporabniki od 1 do N (UE, User Equipment).
Na kompaktnem strežniku CSCF in na aplikacijskih
strežnikih se izvaja programska oprema sistema SI3000
podjetja Iskratel. Karakteristike vsakega izmed
strežnikov in UPSF so: HP Compaq Intel Core 2 CPU
6300, 1.86 GHz procesor, Pentium 4, 1 GB RAM z
Linux i686 (Linux carrier Grade 4.0). PS je MobiCents
[3]. Vsi strežniki imajo povezavo 100 Mbit/s FD in so
priključeni na 24-portno stikalo 3Com Switch 3300 XM
10/100. Kot uporabnika (UE, User Equipment) sta bila
Prejet 23. junij,2012
Odobren 12. september, 2012
http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem
106 GRAŠIČ, KOS
uporabljena terminala Mercuro Bronze [4] in Boghe [5]
ter generator SIPp [6].
Slika 1: Shema analiziranega okolja
2.2 Značilnosti analize vpliva storitev na promet
Izhajamo iz nabora petih storitev, ki jih postavimo v
okolje s tremi aplikacijskimi strežniki. Ugotovimo, da
lahko storitve postavimo na S-CSCF ter na en ali dva
AS. Vsi primeri niso mogoči (npr. za dva AS sta
mogoča samo osnovni klic in IM), tisti, ki so, so
analizirani v nadaljevanju. Analiza se nanaša na
kompaktno verzijo CSCF, kjer nas zanimata izključno
signalni promet in vpliv prometa storitev na S-CSCF in
na vse AS. Značilnost predstavljenega pristopa je v tem,
da prometno analizo razdelimo na posamezne segmente,
to je, da analiziramo promet za vsako storitev posebej.
Slika 2: Osnovni govorni klic prek S-CSCF z dodatno opcijo
izmenjave PRACK in 183
Druge poenostavitve in posebnosti:
 za osnovni govorni klic (BC, Basic Call)
predpostavimo uporabo storitev TIP/OIP,
 za osnovni govorni klic smo poleg najmanjšega
števila sporočil upoštevali tudi dodatne opcije
(PRACK, 183),
 za CDIV smo analizirali samo CFU,
 za analizo IM smo vzeli pozivni način (page
mode), ki uporablja metodo SIP MESSAGE,
 za naročanje smo upoštevali storitev prisotnosti
in registracije,
 za storitev prisotnosti smo v modelu upoštevali
obe možnosti za PS (PS zunaj AS, PS del AS).
2.3 Podrobna analiza prometnih značilnosti
2.3.1 Osnovni klic
Za prometni model za osnovni klic smo vzeli klic brez
dodatnih opcij. Pri osnovnem klicu z dodatno opcijo
PRACK imamo glede na osnovni klic (BC, Basic Call)
dodatno še dve seriji pošiljanja sporočil PRACK. Slika
2 prikazuje osnovni klic prek S-CSCF z dodatno opcijo
izmenjave PRACK in 183.
2.3.2 CDIV
Pri CDIV (CDIV-CFU) so sporočila identična kot za
osnovni govorni klic. Razlika je v tem, da se za CDIV
od AS1 proti uporabniku dodatno pošilja še sporočilo
181 (Call Forwarding), to je obvestilo, da je bila
komunikacija preusmerjena. Prometni model definiramo
kot razliko glede na prometni model za osnovni klic
(definiran kot BC).
Slika 3: Neposredno sporočanje (pozivni način) med
uporabnikom A, S-CSCF, AS1, AS2 in uporabnikom B
2.3.3 CAT
Pri CAT so sporočila identična kot za osnovni govorni
klic. Razlika je v tem, da se iz AS1 klic usmeri proti S-
CSCF in uporabniku B. Ko od uporabnika B dobi
obvestilo o zvonjenju, se od MRF (Media Resource
Function) zahteva predvajanje za ton kontrole poziva po
želji uporabnika. Prometni model definiramo kot razliko
glede na prometni model za osnovni klic (definiran kot
BC). Pri S-CSCF velja, da imamo pošiljanje dodatnega
INVITE od S-CSCF do MRF. Za primer S-CSCF in
AS1 velja, da imamo pošiljanje dodatnega sporočila
AS1
UE-1
UE-N  UPSF
S/P/I-CSCF
AS2 AS3
UE-2
UE-3
PS
STRUKTURIRANJE STORITEV RCS NA APLIKACIJSKEM SLOJU IMS - 2. DEL: PROMET STREŽNIKOV IN PRIMERJAVA… 107
INVITE še iz AS1 do S-CSCF in naprej prek protokola
H.248 do MS (Media Server).
2.3.1 IM
Za IM imamo pošiljanje sporočila MESSAGE, ki ga
uporabnik B potrdi z 200. Slika 3 prikazuje primer
izvajanja IM v primeru S-CSCF ter AS1 in AS2.
2.3.1 Prisotnost
V primeru prisotnosti uporabnik A (vir prisotnosti)
objavlja vsako spremembo stanj s sporočilom PUBLISH
in dogodkovnim paketom Event: presence, ki gre v
smeri od S-CSCF do AS1 in PS.
Slika 4: Objavljanje stanj za storitev prisotnosti med S-CSCF
in AS (ki vsebuje tudi PS), ko sta na objavljanje stanj
naročena dva uporabnika
Vsak uporabnik B (opazovalec prisotnosti) je o
spremembi stanja obveščen s sporočilom NOTIFY in
dogodkovnim paketom Event: presence, ki gre od PS,
AS1, S-CSCF do uporabnika B. Slika 4 prikazuje
izmenjavo sporočil v vmesniku med S-CSCF in AS (ki
vsebuje PS) za primer dveh opazovalcev. Vir prisotnosti
pošlje PUBLISH, ki se  potrdi z 200. Sledi pošiljanje
dveh sporočil NOTIFY s strani AS1 (PS), katerih
prejem se potrdi z 200. Za prometno analizo je treba
upoštevati promet zaradi PUBLISH in promet zaradi
NOTIFY, ki je odvisen od števila opazovalcev (W).
Slika 5: Registracije uporabnika prek S-CSCF (REGISTER,
401, REGISTER, 200), UPSF (MAR, MAA, SAR, SAA) ter
naprej do AS (REGISTER, 200), kjer se nahajajo tri skupine
(G=3) storitev
2.3.1 Registracija
Pri registraciji se do S-CSCF pošlje  REGISTER. Sledi
avtentikacija do UPSF s sporočiloma MAR/MAA
(Multimedia Auth Request/Answer), kar se potrdi s 401.
V drugem delu registracije se pošlje drugi REGISTER,
čemur sledita izmenjava SAR/SAA (Server Assignment
Request/Answer) in potrditev z 200. Pri ponovni
registraciji (re-register) in odjavi (de-register) je
izvajanje enako kot pri prijavi, s tem, da se potrjuje
samo z 200 in da ni dostopov do UPSF. Postopek
registracije prikazuje slika 5.
Pri AS1 se do AS1 pošlje REGISTER, ki se potrdi z
200. Zahtev za registracijo je toliko, kolikor je zapisov
iFC v podatkovni bazi za ta aplikacijski strežnik. V
primeru na sliki 5 se na AS nahajajo tri skupine storitev
(G=3) in s tem trije zapisi iFC v bazi UPSF. Takšen
primer je konfiguracija K1, kot je podana v [2], kjer je
prvi iFC zapis za INVITE (TIP/OIP, CDIV, CAT),
drugi za MESSAGE (IM) in tretji za PUBLISH in
SUBSCRIBE (prisotnost).
2.3.2 Naročanje
Pri naročanju uporabnik pošlje SUBSCRIBE. V primeru
prisotnosti je naročanje sestavljeno iz naročanja na
stanje z dogodkovnim paketom Event: presence ter iz
naročanja na prejemanje informacij o opazovalcih z
dogodkovnim paketom Event:presence.winfo. Pri
registraciji je tudi naročanje na stanje registracije z
dogodkovnim paketom Event: reg. Slika 6 prikazuje
potek naročanja s sporočilom SUBSCRIBE za
dogodkovni paket Event: presence. Posnetek je narejen
med S-CSCF, AS1 in zunanjim PS. SUBSCRIBE se
potrdi z 200, sledi prejemanje informacij o opazovalcih
s sporočilom NOTIFY. Sporočilo SUBSCRIBE se
pošlje za vsakega naročnika, ki je naveden v imeniku.
Slika 6: Naročanje s SUBSCRIBE za Event: presence, ki se
pošlje za vsakega uporabnika, vpisanega v imeniku (od S-
CSCF, AS1 do zunanjega PS)
Tabela 1: Število sporočil, če je v verigi samo S-CSCF
(gledano na S-CSCF) (S: število sporočil)
Seja S (v) S (iz) S
REG 4 4 8
de-REG, re-REG 1 1 2
BC 6 7 13
BC+183 BC+1 BC+1 BC+2
BC+PRACK BC+4 BC+4 BC+8
BC+183+ PRACK
11
BC+5
12
BC+5
23
BC+10
CAT, CDIV BC BC+1 BC+1
IM 1 1 2
Za prometno analizo je tako treba upoštevati promet
zaradi SUBSCRIBE in NOTIFY. Pri registraciji in
dogodkovnem paketu Event:reg imamo promet samo na
108 GRAŠIČ, KOS
S-CSCF. Pri naročanju na prisotnost in dogodkovnem
paketu Event: presence.winfo uporabnik A pošlje eno
zahtevo za naročanje, tej pa sledita 200 in NOTIFY. Pri
naročanju na prisotnost in dogodkovnem paketu
Event:presence uporabnik A pošlje po eno zahtevo za
vsakega uporabnika B, ki se nahaja v imeniku (C:
število kontaktov). Naročanje se potrdi z 200, temu pa
sledi NOTIFY.
2.4 Vpliv podanih storitev na promet strežnikov
Tabela 2: Število sporočil, če sta v verigi S-CSCF in AS1 (S:
število sporočil, G: število skupin, to je števila zapisov iFC za
uporabnika za AS, A: število AS, na katerih se nahajajo
storitve uporabnika, C: število kontaktov)
Storitev Strežnik S (v) S (iz) S
REG S-CSCF 4+1*G*A 4+1*G*A 8+2*G*A
AS1 1*G 1*G 2*G
re-REG
de-REG
S-CSCF
1
1 2+2*G*A
AS1 1*G 1*G 2*G
SUBS S-CSCF 6+4*C*A 6+4*C*A  12+8*C*A
AS1-PS 4+4*C 4+4*C 8+8*C
AS1 + PS 2+2*C 2+2*C 4+4*C
BC S-CSCF 13 13 26
AS1 6 7 13
BC+183 S-CSCF BC+2 BC+2 BC+4
AS1 BC+1 BC+1 BC+2
BC+
PRACK
S-CSCF
BC+8
BC+8 BC+16
AS1 BC+4 BC+4 BC+8
CDIV S-CSCF
14
BC+1
14
BC+1
28
BC+2
AS1
6
BC
8
BC+1
14
BC+1
CAT S-CSCF BC+1 BC+1 BC+2
AS1 BC BC+1 BC+1
IM S-CSCF 4 4 8
AS1 2 2 4
Pres S-CSCF 2+2*W 2+2*W 4+4*W
AS1-PS 2+2*W 2+2*W 4+4*W
AS1+PS 1+1*W 1+1*W 2+2*W
2.4.1 Promet, če je v verigi samo S-CSCF
Prometna analiza za primer, če se storitve izvajajo samo
na S-CSCF, prikazuje tabela 1. Za vsako storitev je
navedeno število sporočil v strežnik in iz strežnika ter
celotno število sporočil. BC pomeni število sporočil za
osnovni klic. Osnovni klic je razširjen še z opcijo
pošiljanja PRACK in 183. Ugotovimo lahko, da je vpliv
prometa zaradi registracije (8) več kot polovica prometa
glede na osnovni klic (13) ter da je promet za osnovni
klic z opcijami (PRACK, 183) še enkrat večji (26) glede
na promet brez dodatnih opcij (13).
2.4.2 Promet, če je v verigi S-CSCF in en AS
Prometna analiza za primer, če se storitve izvajajo na S-
CSCF in enem AS (AS1), prikazuje tabela 2. BC
pomeni število sporočil za osnovni klic, C število
kontaktov v imeniku, A število AS, na katerih se
nahajajo storitve uporabnika, ter G število skupin za
posamezen AS (število iFC zapisov za uporabnika). Pri
registraciji je poleg sporočil za S-CSCF (skupaj 8) treba
upoštevati še dvojico (REGISTER, 200) za vsak zapis
iFC (število skupin storitev) za vsakega izmed
aplikacijskih strežnikov (A: število AS).
Analiza kaže, da je promet na S-CSCF zaradi IM (8)
lahko tretjino prometa osnovnega klica brez dodatnih
opcij (26). Promet zaradi naročanja in registracije
skupaj (10+20=30) je večji od prometa za osnovni klic
(26). Promet za osnovni klic z opcijami (PRACK, 183)
je skoraj še enkrat večji (BC+20) glede na promet brez
dodatnih opcij (BC=26). Ugotovimo lahko tudi, da je
vpliv prometa za storitve, ki temeljijo na govoru (CDIV,
CAT), podoben vplivu za osnovni govorni klic (BC).
Promet zaradi prisotnosti je zelo hitro lahko večji od
prometa za osnovni klic. Če imamo pet opazovalcev, to
pomeni, da imamo na S-CSCF in tudi AS1 24 sporočil
(4+4*5), kar je na S-CSCF skoraj enako kot za osnovni
klic (26) ter še enkrat večje kot na AS1 (13). Velja tudi,
da je pri osmih opazovalcih promet  na S-CSCF
(4+4*8=36) zaradi prisotnosti že enak prometu kot za
osnovni klic prek dveh AS (37).
Tabela 3: Število sporočil, če je v verigi S-CSCF, AS1 in AS2
(S: število sporočil)
Seja Strežnik S (v) S (iz) S
BC S-CSCF 19 18 37
AS1+AS2 11 13 24
BC+183  S-CSCF BC+3 BC+3 BC+6
AS1+AS2 BC+2 BC+2 BC+4
BC+PRACK S-CSCF BC+12 BC+12 BC+24
AS1+AS2 BC+8 BC+8 BC+16
IM S-CSCF 6 6 12
AS1+AS2 4 4 8
2.4.1 Promet, če so v verigi S-CSCF in dva AS
Prometna analizo za primer, če se storitve izvajajo na S-
CSCF in dveh AS (AS1, AS2), prikazuje tabela 3. Tudi
ta analiza kaže, da je na S-CSCF pri osnovnem klicu z
dodatnimi opcijami (PRACK, 183) število sporočil
(BC+30) skoraj še enkrat večje kot brez dodatnih opcij
(BC=37). Analiza tudi kaže, da je promet za IM prek
dveh AS (12) tako rekoč enak prometu zaradi
osnovnega klica v primeru samo S-CSCF (13). Pri
osnovnem klicu vsak strežnik v verigi poveča promet še
za enkrat (S-CSCF: 13, AS: 26, dva AS: 37).
3 MEDSEBOJNA PRIMERJAVA KONFIGURACIJ
IN IZBIRA OPTIMALNE KONFIGURACIJE
Za medsebojno primerjavo konfiguracij [2] smo naredili
primerjavo časovnih parametrov v realnem okolju.
Dodatno smo s simulacijo izvedli primerjavo z uporabo
stroškovne funkcije in parametrov, kjer je bil poudarek
na prometu strežnikov. Za medsebojno primerjavo smo
vzeli za scenarije najosnovnejše storitve RCS, to sta
osnovni klic brez dodatnih opcij (storitev OIP/TIP) in
IM, poleg tega pa še registracijo.
STRUKTURIRANJE STORITEV RCS NA APLIKACIJSKEM SLOJU IMS - 2. DEL: PROMET STREŽNIKOV IN PRIMERJAVA… 109
3.1 Primerjava časovnih parametrov
Za primerjavo časovnih parametrov, ki so podani v
tabeli 4, smo izvedli 1000 meritev s 4 do 12 uporabniki
(uporaba SIPp). Poleg časovnih parametrov (podanih v
ms s standardno deviacijo), ki so definirani v [2], smo
za meritev uporabili še dva druga časovna parametra, to
sta zakasnitev med pošiljanjem INVITE in sprejemom
100 (za uporabnika A) ter med pošiljanjem vzpostavitve
seje 200 in sprejemom potrditve ACK (za uporabnika
B). Pri osnovnem klicu in IM se za K1-K4 seja
vzpostavi prek dveh AS.
Tabela 4: Primerjava časovnih parametrov (v ms)
Parameter Start-stop K0 Stdv K1-K4 Stdv
SRD INVITE-180 72 1 316 12
INVITE-100 INVITE-100 14 11 10 2
200-ACK 200-ACK 20 0 84 7
SDD BYE-200 19 1 11 3
SMD MESS-200 54 0 313 13
RRD1 REG-401 56 1 55 9
RRD2 REG-200 95 7 101 14
RRD REG-200 148 18 152 26
re-REG REG-200 78 13 66 5
de-REG REG-200 100 14 115 14
3.2 Izbrani scenariji za podane konfiguracije
Za medsebojno primerjavo smo definirali štiri scenarije,
s podatki za glavno prometno uro, kot so definirani v
tabeli 5. Za osnovni klic smo privzeli 4 klice (0.1 erl),
za IM od 1 do 12 SMS-jev (glede na ugotovitve, podane
v [4]), ter od 0 do 4 registracije. Za simulacijo smo vzeli
10 meritev s 120 do 1200 uporabniki.
Tabela 5: Izbrani scenariji za medsebojno primerjavo
konfiguracij (število sprememb za glavno prometno uro)
Scenarij BC IM Reg Ime scenarija
SC1 4 8 1 Avg
SC2 4 12 1 AvgIM
SC3 2 2 4 MinReg
SC4 4 1 - Bc
3.3 Izbira in izračun stroškovne funkcije
Za stroškovno funkcijo, ki smo jo poimenovali C1, smo
izhajali iz obremenitve strežnikov. Za C1 smo izbrali
vsoto parametra promet na S-CSCF (TS) in največji
promet na vseh AS (TASmax) za glavno prometno uro.
Velja formula C1=TS+TASmax.
Slika 7 prikazuje stroškovno funkcijo (število
sporočil v glavni prometni uri v 1000) za SC1 (Avg) v
odvisnosti od števila uporabnikov. Razvidno je, da je
funkcija linearna. Iz slike je razvidno, da je stroškovna
funkcija najmanjša za K1, takoj za tem pa za K4.
Razmerje stroškovne funkcije med K2 in K1 ter med K3
in K1 je 1.14, ter med K4 in K1 1.04. Podobno velja za
stroškovno funkcijo za SC3 (MinReg), ki je podana na
sliki 8. V tem primeru velja, da je stroškovna funkcija
najmanjša tako za K1 kot tudi za K4. Razmerje
stroškovne funkcije za K2 in K3 ostaja enako (1.14). Je
pa manjša vrednost C1 za K1 za 1200 uporabnikov
(194.400 signalov za SC1 proti 135.600 za SC3).
Slika 7: Stroškovna funkcija C1 za SC1(Avg) (v 1.000) v
odvisnosti od števila uporabnikov (optimalna izbira: K1)
Slika 8: Stroškovna funkcija C1 za SC3 (MinReg) (v 1.000) v
odvisnosti od števila uporabnikov (optimalna izbira: K1, K4)
3.4 Primerjava konfiguracij po parametrih
V tabeli 6 smo primerjali konfiguracije za primer SC1.
To so normirani podatki na uporabnika. Za vse
konfiguracije (K1-K4) velja, da je obremenitev na S-
CSCF (NUTS), konfiguraciji (NUTC) in povprečna na
AS (NUTASavg), enaka. Zakasnitev na INVITE poti je
glede na K0 večja za faktor 4.39 (NSSRD), povprečno
je AS obremenjen s faktorjem 0.21 glede na S-CSCF
(NSTASavg). Razlika je v največji obremenitvi AS
(NUTAsmax) in razmerju obremenitev AS (TASmm).
Tabela 6: Primerjava parametrov za SC1 (posivljeni so
parametri, ki se razlikujejo med konfiguracijami)
Parameter K0 K1 K2 K3 K4
NUTS 42 134 134 134 134
NUTC 42 218 218 218 218
NUTASmax 0 28 50 50 34
NUTASavg 0 28 28 28 28
TASmm - 1 - - 1.36
NSSRD 1 4.39 4.39 4.39 4.39
NSTASavg 0 0.21 0.21 0.21 0.21
NSTASmax 0 0.21 0.37 0.37 0.25
NSTASall 0 1.63 1.63 1.63 1.63
Tabela 7 kaže primerjavo konfiguracij za vse štiri
scenarije. Za K0 velja, da je NUTS=NUTC. Izbire, ki so
110 GRAŠIČ, KOS
najbolj optimalne, so posivljene. V vseh primerih je
najbolj optimalna izbira K1. V primeru SC3 je
optimalna izbira tudi K4, vendar za SC2 izbira K4
pomeni tudi največji TASmax.
Tabela 7: Normiran promet na uporabnika na S-CSCF
(NUTS), konfiguracijo (NUTC) in najbolj obremenjenem AS
(TASmax) (posivljene so optimalne izbire)
SC K0 K1 K2 K3 K4
SC1 42 134/218/28 134/218/50 134/218/50 134/218/34
SC2 46 158/258/33 158/258/50 158/258/50 158/258/50
SC3 47 97/145/16 97/145/32 97/145/32 97/145/16
SC4 27 80/132/17 80/132/48 80/132/48 80/132/24
3.5 Predlog postavljanja storitev
Za postavljanje storitev predpostavimo, da so AS enako
zmogljivi (TASmax), S-CSCF pa je lahko močnejši.
Ugotovimo, da je potrebna procesna moč za S-CSCF
(TS) in celotno konfiguracijo (TC) za poljuben scenarij
tako rekoč enaka. Bistvena razlika obstaja pri
obremenitvi posameznih AS (TASmax, TASmm).
S stališča stroškovne funkcije C1 je najbolj optimalna
konfiguracija K1. Rešitev je skalabilna in je najbolj
optimalna tudi za večje število uporabnikov. Pogoj je,
da je na vseh AS enako število uporabnikov. Dodaten
pogoj je ustrezna zmogljivost AS glede na S-CSCF.
Glede na tabelo 6 je obremenitev za K1 na najbolj
obremenjenem AS glede na S-CSCF (NSTASmax)
enaka 0.21 (na splošno niha med 0.21 in 0.37).
Če privzamemo kot osnovni scenarij SC1 ter
osnovno (optimalno) konfiguracijo K1, nas zanima
primerjava drugih scenarijev in konfiguracij glede na
SC1 za K1. Relativno razmerje prikazuje tabela 8. Za
K1 do K4 je razmerje prometa na S-CSCF od 0.60 do
1.18 ter za celotno konfiguracijo od 0.99 do 1.93.
Odstopanje za različne scenarije in s tem za najmanjšo
in največjo obremenitev je za oba primera skoraj za
faktor 2. Podobno velja za največjo obremenitev AS.
Razvidno je tudi nihanje obremenitve na AS (TASmax)
glede na obremenitev na S-CSCF (TS) za različne
scenarije. V primeru K1 je to nihanje med 0.12 in 0.37.
Tabela 8: Relativno razmerje prometa na S-CSCF (ts),
konfiguraciji (tc) in najbolj obremenjenem AS (tmax) glede na
promet na S-CSCF (ts) v primeru SC1 za K1 (posivljene so
najnižje vrednosti)
K0 K1-K4 K1 K2 K3 K4
ts ts tc tmax tmax tmax tmax
SC1 0.31 1.00 1.63 0.21 0.37 0.37 0.25
SC2 0.34 1.18 1.93 0.25 0.37 0.37 0.37
SC3 0.35 0.72 1.08 0.12 0.24 0.24 0.12
SC4 0.20 0.60 0.99 0.13 0.36 0.36 0.18
Iz tabele 8 je razvidno, da bi bila dokaj optimalna tudi
konfiguracija K4.  Posebnost K4 je v tem, da so govorne
storitve posebej (AS1, AS2), storitve RCS pa  posebej
(AS3). Če bi ne imeli SC2, za katero je značilno
pošiljanje večjega števila SMS/MMS, bi bilo pri
največji obremenitvi za SC1 povečanje največje
obremenitve AS na K4 (obremenitev 0.25) za manj kot
20 % večje kot na K1 (obremenitev 0.21).
4 RAZPRAVA IN SKLEP
V drugem članku smo za strukturiranje aplikacijskega
sloja postavili model vpliva storitev na promet
strežnikov, podane konfiguracije s pomočjo stroškovne
funkcije in parametrov primerjali za štiri različne
scenarije obnašanja ter predlagali postavljanje storitev.
Analiza vpliva posameznih storitev na promet
strežnikov kaže, da so določeni prometni vplivi na S-
CSCF lahko do dvakrat večji kot za osnovni klic brez
dodatnih opcij. Dodatno rezultati analize konfiguracij za
štiri scenarije obnašanja za osnovni klic, IM in
registracijo kažejo, da je  potrebna procesna moč za S-
CSCF in celotno konfiguracijo za posamezen scenarij
enako velika, razlika se kaže pri obremenitvi
posameznih AS. Očitno je obremenitev AS ključni
podatek za stroškovno funkcijo in dilema je, kako še
nadgraditi stroškovno funkcijo.
Najbolj optimalna je konfiguracija K1, kjer se vse
storitve nahajajo na vsakem izmed AS. Dilema, ki se
odpira, je, v kakšnih okvirih (odstopanjih obremenitve)
in scenarijih bi še bila optimalna tudi konfiguracija K4.
Vse te dileme bodo osnova bodočih raziskav,
simulacij in meritev. Dodatno bomo raziskave razširili
na vse analizirane storitve, na več različnih scenarijev
obnašanja za uporabnike in storitve ter na nadgradnjo
stroškovnih funkcij.