VoIP

[Wozniak jR.]

//UPDATE : gotovo postavljanje

Stavit cu u ovu temu svoj zavrsni rad o VoIP-u, pa bih vas molio da ne komentirate odmah jer ću ga razbiti na par postova ( ima toga puno ) jer će mi tako biti lakše formatirati sve i ubaciti slike.
Ima gramatickih pogresaka i "ne prevedenog teksta" zbog problema sa rokom pisanja i slično. Ugl, kritike slobodno pucajte pa ću valjda promijenit naknadno

Rađeno je po knjizi " Syed A. Ahson, Mohammad Ilyas: „ VoIP HANDBOOK - Applications, Technologies, Reliability, and Security“, CRC press Taylor & Francis Group, NW, 2009. " ;
te tako na kraju svakog odlomka stoji [broj knjige ( 1 ) : broj stranice ] ( copyright razlozi )

Uglavnom, nadam se da će ovo nekome biti korisno...

popis oznaka ( ako se izgubite u tekstu ) :

VoIP – Voice over Internet Protocol
IP – Internet Protocol
QoS – Quality of Service
ERP – Enterprise resource planning
PSTN - PublicSwitched Telephone Network
PCM - Pulse code modulation
PBX - Private Branch eXchange (PBX)
ITU-T - International Telecommunication Union-Telecommunication
CDRs - Call Detail Records
CAC - Call admission control
TCP - Transmission control protocol
TELR - Talker echo loudness rating
FEC - Forward error correction
PLC - Packet loss concealment
LSC- Local session controller
MPLS - Multi-protocol label switching
PHB - per hob behaviors
DS Field - Differentiated service field
DSCP - Differentiated services code point
SIP - Session initiation protocol
(S)RTP - (secure) real-time transport protocol
UDP - user diagram protocol
SSL / TSL - secure socket layer / transport layer security
UA - user agent
ITU - International Telecommunication Union
MCU - multipoint control unit
BES - back end service
NAT - network address translation
SPIT - spam-over.internet telephony
DHCP - Dynamic Host Configuration Protocol
DoS - Denial of Service
HSPD – high-speed packet-switched data
RLP - radio link protocol
UTRA - UMTS terrestrial radio access
EVDO - evolution data optimized
LTE - long-term evolution
UMB - ultra mobile broadband
TDM - dime division multiplexing
HARQ - hybrid automatic repeat request
BTS - base transceiver station
RAN - radio access network
OFDMA - orthogonal frequency division multiple access
MIMO - multiple input multiple output
SDMA - spartial diversity multiple access
EVRC - enhanced variable rate codec
ROHC - robust header compression
PDSN - packet data service node
MUP - multiuser packet
PER - packet error rate
DRC - data rate control
DSC - data source control
FLSS - fast link serving sector
RLSS - reverse link serving sector
AP - access point
LPR - loss packet rate
TXOP - Tx Opportunity

[Wozniak jR.]

1. IMPLEMENTACIJA VoIP-a U POSTOJEĆE IP MREŽE
1.1 Uvod

Mnogi mrežni administratori smatraju atraktivnim i jeftinim rješenjem spajanje glasovnog i podatkovnog prometa. Ujedinjenu mrežu je lakše pokrenuti, upravljati i održavati. Međutim, većina današnjih postojećih podatkovnih mreža je bazirana na Ethernetu i Internet Protokolima (IP) [1:3].
Takve mreže nisu dizajnirane za podršku aplikacijama koje rade u stvarnom vremenu, kao što je VoIP. VoIP zahtjeva pravovremenu dostavu paketa s malom latencijom, gubitkom paketa i zadovoljavajućom propusnošću. Kako bi postigli ovo, učinkovita implementacija VoIP-a će biti moguća ako se pobrinemo da su prijenosi prometa u stvarnom vremenu mogući na novoj ili postojećoj IP mreži [1:4].
Kada se VoIP implementira u postojeću mrežu mnogi mrežni arhitekti, planeri i projektanti, su suočeni sa zajedničkim izazovima i pitanjima. Koji su zahtjevi za Quality of service (QoS)? Kako će novi VoIP utjecati na QoS postojećih servisa i aplikacija? Hoće li postojeća mreža podržavati VoIP i zadovoljavati standarde QoS? Ako da, koliko VoIP poziva mreža može podržati prije nego li postane potrebno nadograditi neke od fizičkih dijelova mreže [1:4]?
Neki od komercijalnih alata mogu odgovoriti na ova pitanja, a temelje se na dva pristupa za procjenu implementacija VoIP-a u postojeću mrežu. Jedan pristup se bazira na mjerenju mreže i procjeni spremnosti mreže za implementaciju VoIP-a. Drugi se bazira na fizičkom puštanju VoIP prometa preko mreže te mjerenju latencije, zastajkivanja te gubitka podataka [1:4].
Komercijalni alati koštaju, no nijedan alat ne daje sveobuhvatni pristup uspješnoj VoIP implementaciji. Konkretno, nijedan ne može predvidjeti ukupni broj poziva koji može podržati mreža, uzimajući u obzir važne inženjerske i dizajnerske odluke, niti budući rast u kapacitetu ni utjecaju VoIP-a na postojeće servise i aplikacije te utjecaj pozadinskog prometa na VoIP [1:4].

1.2 Koraci implementacije

U ovom poglavlju će biti objašnjeno 8 koraka u uspješnoj implementaciji VoIP-a (Slika 1 [1:5]). Prva četiri koraka su neovisna te se mogu izvoditi u paraleli. Koraci šest i sedam, analiza i simulacije, se također mogu izvoditi u paraleli no korak 5 uključuje rano i potrebno redimenzioniranje ili modifikaciju na postojećoj mreži. Zaključni korak je faza implementacije [1:4].



Slika 1 : Shema implementacije VoIP mreže

Ova metodologija može biti korištena i pri implementaciji drugih mrežnih servisa; video-konferencije, peer-to-peer (p2p), mrežnog igranja, Internet Protocol televizije (IPTV), planiranja resursa (ERP) ili SAP servisa [1:5].

1.2.1 VoIP obilježja, zahtjevi i pretpostavke

Kako bi se uveli novi servisi kao što je VoIP moraju se prvo utvrditi obilježja prometa, QoS zahtjevi te potreba za dodatnim komponentama ili uređajima. Zbog jednostavnosti pretpostavljamo point-to-point konekcije za sve VoIP pozive. Prvo, gatekeeper ili Callmanager čvor, koji može upravljati signalizacijom do uspostavom, prekidanjem i autorizacijom svih VoIP konekcija, mora biti dodan u mrežu. Isto tako je potreban i VoIP gateway odgovoran za pretvorbu VoIP poziva od/prema PublicSwitched Telephone Network (PSTN) kako bi upravljao vanjskim pozivima. Sa stajališta inženjera i dizajnera mreže, postavljanje ovih čvorova u mrežu je kritično. Ostali hardverski zahtjevi uključuju VoIP klijent terminal koji može odvajati VoIP uređaje (IP telefon) i tipična računala ili radne stanice sa VoIP software-om [1:5].




Slika 2 : end-to-end komponente VoIP-a
Slika 2 ([1:6]) prikazuje end-to-end VoIP komponente, od slanja do primanja. Prva komponenta je koder, koji periodično uzorcima izvornog glasa dodjeljuje stalni broj bita te stvara konstantni tok bitova. Tradicionalni koder G.711 koristi pulsno-kodnu modulaciju (PCM) kako bi generirao 8-bitne uzorke svakih 0.125ms. To vodi do protoka podataka od 64kbps. Iza njega sljedi packetizer, koji enkapsulira određeni broj govornih uzoraka u pakete i dodaje im RTP, UDP, IP i Ethernet zaglavlja. Paketi putuju kroz mrežu do primaoca gdje je bitna komponenta reprodukcijski spremin koja ima cilj apsorbirati varijacije trzaja u kašnjenju te tako osigurati glatko reproduciranje. Paketi se nakon toga prosljeđuju na depacketizer te nakon toga na dekoder, koji rekonstruira početni glasovni signal [1:6].

1.2.1.1 End-to-end kašnjenje za pojedini glasovni paket

Slika 2 je ilustrirala izvore kašnjenja za tipične glasovne pakete. End-to-end kašnjenje se nekada naziva i mouth-to-ear (M2E) kašnjenje. Kodek G.714 nameće maksimalno kašnjenje za jedan paket 150ms u end-to-end VoIP aplikaciji [1:6].
Kašnjenje do 200ms se smatralo prihvatljivim. Ovo kašnjenje može se rastaviti na tri komponente [1:7]:
1. Kodiranje, kompresija i packetization kašnjenje na pošiljateljevom kraju
2. Propagacija, slanje i upitno kašnjenje u mreži
3. Dekompresiranje, depacketization , dekodiranje i reprodukcijsko kašnjenje na strani primaoca.

1.2.1.2 Širina pojasa za jedan poziv

Potrebna širina pojasa za jedan poziv u jednom smjeru je 64kbps. Kako G.711 kodek uzima uzorke od 20ms po paketu, 50 takvih paketa se može proslijediti u sekundi. Svaki paket sadrži 160 glasovnih uzoraka, što daje 8000 uzoraka po sekundi. Svaki paket je poslan u jednom Ethernet okviru. Na svaki paket veličine 160 bytova se dodaju zaglavlja dodatnih protokola. Ovo zaglavlje uključuje RTP + UDP + IP + Ethernet, sa veličinama 12 + 8 + 20 + 26. Sveukupno 226 byte-ova ili 1808 bit-ova mora biti preneseno 50 puta u sekundi, ili 90.4kbps, u jednom smjeru. Za oba smjera, potrebna je širina pojasa od 180.8kbps [1:7].

1.2.2 Protok VoIP prometa i raspodjela poziva

Prije daljnje analize ili planiranja VoIP bitno je skupiti statistike trenutne količine korištenja telefonskih usluga, kako bi se uspješno implementirao VoIP. Izvori takvih informacija su privatne centrale organizacije (PBX), telefonski zapisi i računi. Ključne karakteristike postojećih poziva uključuju broj poziva, broj istovremenih poziva, vrijeme i trajanje poziva itd. Bitno je odrediti početak i kraj poziva, odnosno njegovo izvorište i odredište. To će pomoći pri identificiranju distribucije poziva na unutrašnje i vanjske. Distribucija poziva mora uključivati postotak poziva koji su napravljeni unutar i izvan kata, zgrade, odjela ili organizacije. Preporučeno je da se ta analiza poziva bazira na naj zauzetijem danu, tjednu ili mjesecu. Ovo će osigurati podršku za sve pozive u svako vrijeme, te time voditi do velikog QoS-a za sve VoIP pozive. Kada se takvi podatci kombiniraju s planiranim dodatnim pozivima, može se predvidjeti te predstaviti najgori mogući slučaj VoIP opterećenja u toj mreži [1:7].

1.2.3 Definiranje ograničenja radi budućeg rasta

Definiraju se ograničenja performansi bitnih mrežnih elemenata. Ova ograničenja se razmatraju pri uvođenju novih usluga. Profit je dvostruki. Prvo, zahtjevi nove usluge su zadovoljeni te dodavanje novih usluga ostavlja mrežu zdravom i sposobnom za rast u budućnosti [1:8].
Dva bitna kriterija treba uzeti u obzir: prvo, maksimalno end-to-end kašnjenje;
drugo, upotreba granica mrežnih resursa. Maksimalno prihvatljivo end-to-end kašnjenje se određuje sa najosjetljivijom aplikacijom na mreži. U ovome slučaju, 150ms end-to-end za VoIP. To je bitno ako mreža ima par aplikacija osjetljivih na kašnjenje, kao što je recimo kašnjenje VoIP prometa, kako ne bi premašili potrebne maksimalne vrijednosti. Što se tiče granica mrežnih resursa, one su određene faktorima kao što su trenutna iskoristivost, budući planovi te predviđeni rast mreže. Ispravni resursi i planiranje kapaciteta su presudni. Mrežni inženjeri moraju razvijati nove servise sa unaprijed isplaniranom skalabilnošću te utvrditi da će mreža dati zadovoljavajuće rezultate pod teškim opterećenjem, bez gubitka paketa. VoIP zahtjeva minimalan, odnosno nikakav gubitak podataka [1:8].
Rast korisnika, mrežnih servisa, poslova itd. mora biti uzeto u obzir da bi se izvelo povećanje kapaciteta. U praksi, ostavlja se 25% dostupne mrežnog kapaciteta za budući rast. Radi jednostavnosti, ovo se primjenjuje ravnomjerno na sve mrežne resurse poput usmjernika i preklopnika. No, mora se uzeti u obzir da ovaj postotak varira o svakoj mreži te može ovisiti o budućim planovima [1:8].
1.2.4 Mrežna mjerenja

Mjerenje mreže karakterizira postojeći promet, upotrebu i protok. Mjerenje mreže je presudan korak jer može utjecati na rezultate koji se koriste u analitičkoj studiji i simulaciji. Postoji mnoštvo komercijalnih i nekomercijalnih alata za mjerenje mreže. Popularni open-source alati su MRTG, STG, SNMPUtil i GetIF.Popularni komercijalni alati su HP OpenView, Cisco Netflow, Lucent VitalSuite, Patrol DashBoard, Omegon NetAlly, Avaya ExamiNet i NetIQ Vivinet Assessor [1:8].
Mjerenje mreže mora biti determinirano za elemente kao što su usmjernici, preklopnici i linkovi. Mnogobrojni tipovi mjera i statistika mogu biti sakupljeni koristeći alate za mjerenje. Kao minimum, promet u bitima po sekundi (bps) i paketi po sekundi (pps) moraju biti mjereni za linkove direktno spojene na usmjernik i preklopnik. Da bi dobili odgovarajuće procjene, mrežna mjerenja moraju biti provedena kroz dugi period vremena, najmanje 24sata. Katkad je poželjno provoditi mjerenja kroz par dana [1:8].
Mrežni inženjeri moraju uzeti u obzir najgori scenarij, kada je mreža potpuno opterećena, kako bi osigurali dobar QoS cijelo vrijeme, uključujući sate s najviše prometa. Sat s najviše prometa je drukčiji za svaku mrežu te ovisi o vrsti posla i uslugama koje mreža osigurava. [1:9]

1.2.5 Procjene i izmjene

U ovom koraku se može procijeniti postojeću mrežu i da li joj treba modifikacija na temelju postojećeg prometa i zahtjeve usluga koje će biti postavljene. Modifikacije mogu uključivati postavljanje novih servera ili uređaja (kao što su VoIP gatekeeper, gateway i IP telefoni), nadogradnja računala i redimenzioniranje jako opterećenih linkova. Kao dobro pravilo, promjene topologije moraju biti minimalne te ne bi trebale biti napravljene ukoliko nisu potrebne i opravdane. Nepotrebne nadogradnje koštaju puno novaca i smatraju se lošim dizajnom mreže [1:9].
Mrežni inženjeri moraju uzeti u obzir postojeće opterećenje prometom. Ako je bilo koji link jako iskorišten, recimo 30-50%, inženjer bi trebao razmisliti o njegovom redimenzioniranju te postavljanju na 1Gbps. Za dijeljene linkove treba razmisliti, dijeljeni Ethernet nije lako skalabilan te ga nije preporučljivo mijenjati gdje su aplikacije u stvarnom vremenu te aplikacije s kašnjenjem [1:9].

1.2.6 Analiza

VoIP je omeđen s dva jako bitna mjerila; prvo, raspoloživa propusnost, i drugo
end-to-end kašnjenje. Stvarni broj VoIP poziva koje mreža može održavati i podnijeti je omeđena s ova dva podatka. Ovisno o upitnoj mreži, ključni faktor kod određivanja broja poziva su ili propusnost ili kašnjenje. Analize koje se provode su analiza propusnosti te analize kašnjenja [1:9].

1.2.7 Simulacija

Cilj simulacije je potvrditi rezultate analize o podršci VoIP poziva. Postoje mnogi simulacijski paketi koji mogu biti korišteni, uključujući komercijalne i open-source [1:15].

1.2.8 Implementacija

Prije izmjene bilo kakve mrežne opreme, preporuča se projekt implementacije VoIP-a u testnom laboratoriju, kako bi se uvjerili u glatku ugradnju i tranziciju s minimalnim prekidom mrežnih usluga. Projekt implementacije se obavlja nakon treninga IT osoblja. Ovo je mjesto gdje mrežni inženjeri te podrška mogu iz prve ruke provjeriti VoIP sisteme i njihovo ponašanje. Tijekom ove implementacije novi VoIP uređaji se provjeravaju, konfiguriraju, testiraju te prate. Cijeli tim mora biti upoznat s tim kako VoIP radi, kako se miješa s drugim prometom te kako dijagnozirati i riješiti jednostavne probleme. Jednostavni VoIP pozivi mogu biti uspostavljeni u svrhu testiranja [1:15].

Primjer implementiranja VoIP-a

U ovom dijelu će biti predstavljen primjer tipične IP mreže malog poslovnog poduzeća. Ukratko će biti opisana metodologiju uspješnog implementiranja VoIP-a u ovu mrežu. Primjer je prikazan na na Slika 3 ([1:16]). Mreža je bazirana na Ethernetu te ima dva Layer-2 Ethernet switcha spojena na router. Usmjernik je Cisco 2621 a preklopnici 3Com Superstack 3300. Preklopnik1 spaja Floor1, Floor2 i dva servera, dok Preklopnik2 spaja Floor3 i četiri servera. Svaki floor (kat) je jednostavno dijeljena Ethernet konekcija do zaposlenikovog računala sa radnom grupom i print serverom. Ova mreža koristi VLAN kako bi izolirali broadcast i multicast promet. Sveukupno postoji 5 LAN-ova, a svi VLAN-ovi su bazirani na portovima. Preklopnik1 je konfiguriran tako da ima tri VLAN-a. VLAN1 uključuje bazu podataka i podatkovne servere [1:15].



Slika 3 : Topologija male mreže poduzeća

VLAN2 uključuje Floor1, VLAN3 Floor2 a VLAN5 Floor3. Preklopnik2 je konfiguriran kako bi imao dva VLAN-a. VLAN4 uključuje servere za e-mail, HTTP, Web i firewall. Svi linkovi su Ethernet 100Mbps full-duplex, osim linkova za Floor1,2,3 koji su dijeljeni Ethernet 100Mbps half-duplex [1:16].
Zbog unaprijed procijenjenog stanja i hardware-skih potreba kako bi se implementirao VoIP, u petom koraku se dodaju dva nova čvora u postojeću mrežu: VoIP gateway i gatekeeper. Zbog problema u dizajnu mreže, ova dva čvora moraju biti postavljeni odgovarajuće. Kako je većina korisnika na Flooru1 i Flooru2 te su direktno spojeni na Preklopnik1, spajanje gatekeepera na Preklopnik1 je praktično i tako održava promet lokalno. VoIP gateway spajamo na Preklopnik2 kako bi ravnomjerno rasporedili opterećenje na oba preklopnik-a [1:16].
Isto tako, pouzdanija metoda i isto tako otpornija na grešku je da se ne spajaju oba čvora na isti preklopnik kako bi se mogli eliminirati problemi koje uzrokuje jedna točka. Npr, ako Preklopnik2 zakaže samo će vanjski pozivi prema i od mreže biti onemogućeni. Gatekeeper se treba dodati kao član VLAN1 Preklopnik-a1, koji uključuje bazu podataka i file server. Ovo izolira gatekkeper-a od multicast i broadcast prometa sa Floora1 i Floora2. Kao dodatak, gatekeeper može pristupiti bazi podataka i file serverima kako bi snimao i zapisivao telefonske pozive. Možemo i razdvojiti VLAN za gateway kako bi izolirali gateway od multicast i broadcast prometa na Flooru3 i sa servera na Switcu2. Tako mreža sada ima sveukupno šest VLAN-ova. Slika 4 ([1:17]) prikazuje novu mrežnu topologiju nakon unesenih promjena VoIP komponenti [1:16].



Slika 4 : Topologija s potrebnim VoIP komponentama

Kao što je prikazano, dva nova gatekeeper i gateway čvora su dodana te su tri dijeljena Ethernet LAN-a zamijenjena sa 100Mbps Ethernetima sa preklopnicima [1:17].
Za šesti korak analize postoje dvije mogućnosti provedbe. Jedna koristi MATLAB, a druga analitički simulator sa grafičkim sučeljem. U prvoj mogućnosti, MATLAB programi mogu biti napisani za implementiranje analize propusnosti i kašnjenja. Algoritam 1 je nastao korištenjem MATLAB-a te se rezultat za najgore kašnjenje može vidjeti na Slika 5 ([1:18]). Iz slike se može zaključiti da se kašnjenje drastično pogoršava kada broj poziva prijeđe 310. Preciznije, MATLAB rezultati pokazuju kašnjenje od 80ms za 315 poziva. Iz analize propusnosti za MaxCalls, za sve mrežne elemente, dolazi do zaključka da je usmjernik ograničavajući faktor. Stoga, TotalCallsSupported je 313. Kada gledamo koliko poziva mreža može podnijeti, bazirano na propusnosti i najgorem kašnjenju, vidimo da je broj poziva više ograničen propusnošću nego kašnjenjem, iako je razlika mala. Stoga, možemo zaključiti da je maksimalni broj poziva koje mreža može podnijeti 313 [1:17].
Druga mogućnost je fleksibilnija i prikladnija jer izbjegava korištenje MATLAB-a. Koristi analitički simulator sa grafičkim sučeljem koji radi na bilo kojoj mreži. Simulator ima grafičko sučelje pomoću kojega može biti napravljena mrežna topologija. Drugim riječima, simulator ima ugrađenu drag-and-drop komponentu kako bi se napravila mrežna topologija te poslala u analitički engine. Ovaj simulator dopušta korisnicima da postave i konfiguriraju mnoge postavke i parametre koji se odnose na VoIP implementaciju. U roku par sekundi simulator daje rezultat koliko VoIP poziva može biti podržano. Rezultati dobiveni od simulatora i MATLAB-a su isti [1:17].



Slika 5 : najgore kašnjenje u odnosu na broj poziva

Slika 6 ([1:19]) pokazuje odgovarajući mrežni model složen sa VoIP simulatorom za mrežnu topologiju sa slike 1.4. Kako bi se izbjeglo postavljanje hrpe računala i IP telefona na svaki kat kako bi predstavljali korisnike (i time zagušivali dijagram), LAN-ovi s katova su jednostavno stavljeni kao LAN-ovi koji obuhvaćaju Ethernet preklopnik i tri računala koju prikazuju korisnika na LAN-u. Primjer; Floor1 ima tri čvora (označeni F1C1,F1C2 i F1C3), F1C1 služi za slanje odlaznih poziva , F1C2 za primanje poziva i F1C3 za pozadinski promet. Ovaj model omogućava generiranje pozadinskog prometa i uspostavu poziva unutar kata ili između F1C1 i F1C2, prolazeći kroz preklopnik F1SW. Čvorovi F1C1 i F1C2 imaju neograničen kapacitet, odnosno ne postoji limit koliko poziva mogu primiti ili uputiti. Ignoriramo promet koji generira gatekeeper [1:18].

Slika 7 pokazuje analize propusnosti i kašnjenja. Slika 7a prikazuje broj poziva koji mogu biti uspostavljeni ovisno o analizi propusnosti: 315 poziva je moguće u cijeloj mreži. Kako bi indentificirali moguće usko grlo, izvještaj prikazuje i individualne pozive koji mogu biti podržani od strane čvora i linka. Ovdje je prikazan usmjernik kao usko grlo te bi ga bilo potrebno zamijeniti kako bi podržali više od 315 poziva. Slika 7b prikazuje broj poziva koji mogu biti uspostavljeni bazirano na analizi mreže; 313 poziva može biti uspostavljeno prije nego se pređe dozvoljeno kašnjenje od 80ms. Prikazano je da sa 313 poziva mreža ima kašnjenje od 16.75ms. To znači da ako dođe do još samo jednog poziva, povećalo bi se kašnjenje i prešli bi dozvoljenih 80ms. Slika 1.7b prikazuje mrežno kašnjenje ovisno o ruti (putu). U našem slučaju to je 9 ruta [1:18].



Slika 6 : odgovarajući mrežni dijagram konstruiran u analitičkom simulatoru

Pomoću OPNET-a je potvrđen analitički pristup. Sa OPNET simulacijom, broj VoIP poziva koji može biti podržan iznosi 306. Iz rezultata analize i simulacije je vidljivo da su oba rezultata približna. Razlika između analitičkog pristupa i OPNET-a je u samo 7 poziva. Ta razlika se može pripisati stupnju točnosti između analitičkog pristupa i OPNET simulacije. Analitički pristup je aproksimacija. Najsigurnije je uzeti u obzir najmanji broj koji smo dobili s oba pristupa [1:19].
Dizajn mreže i inženjerske odluke mogu biti opravdane analitičkim i simulacijskim perspektivama. Prvo, postojeća mreža, sa čuvanim rastom od 25%, može sigurno podržati 306 poziva dok se pridržavaju VoIP QoS zahtjeva i nemaju negativni utjecaj na performanse postojećih mrežnih servisa ili aplikacija. Drugo, usko grlo mreže je usmjernik, koji može biti zamijenjen sa Layer-3 Ethernet preklopnikom. Prije nego se naprave bilo kakve druge promjene, mora se provjeriti koliko se poziva može obaviti istovremeno nakon zamjene usmjernika. Kako bi postigli ovo, koraci koje smo prije prošli moraju biti ponovljeni. Mrežni kapacitet za podršku VoIP-a više ovisi o propusnosti mreže nego o kašnjenju. Ovo je zato jer je razmatrana mreža malena , no kašnjenje može postati dominantni problem ako se radi o većim LAN-ovima ili WAN-ovima [1:19].



Slika 7 : a) Izvješće o propusnosti b) izvješće o kašnjenju

[Wozniak jR.]

2.1 Evolucija usluga u mobilnim mrežama

VoIP je brzo postao popularan u fiksnim mrežama. Evolucija govornih usluga iz fiksnih u VoIP se događa zbog IP mreža koje mogu isplativije isporučivati bitove podataka. Slično kao i fiksna mreža, VoIP je u bežičnim mobilnim mrežama započeo sa circuit-switched mrežama. Od razvoja prvog komercijalnog bežičnog sistema, bežične mreže su se razvile iz prve generacije analognih mreža u drugu generaciju digitalnih mreža. Mreže treće generacije koje se trenutno koriste pružaju visoku efikasnost circuit-switched servisa i imaju duplo veću spektralnu efikasnost mreža druge generacije. Broj korisnika se nije povećavao nakon što je dosegnuta granica nakon uvođenja treće generacije mreža. Fokus sa bežičnog sustava se prebacio na bežične podatkovne aplikacije. Ovo je rezultiralo pojavom high-speed packet-switched data (HSPD) mreža koje su postepeno razmještene u circuit-switched mrežama diljem svijeta [1:52].

Rast HSPD mreža je učinio poželjnijim ponuditi glasovne usluge koristeći VoIP zajedno sa podatcima kao potporu vrlo raznolikim multimedijskim uslugama. Kad se HSPD i VoIP razvijaju zajedno posebna circuit-switched mreža ne mora biti posvećena glasovnim uslugama. Uz to, kako je većina HSPD mreža dizajnirana koristeći najnovije tehnologije, spektralna učinkovitost mobilne VoIP mreže može biti uvelike poboljšana. To čini mobilni VoIP privlačnim davateljima usluga koji se suočavaju s ograničenjima dostupnosti frekvencijskog spektra; oni također imaju prednost da integrirana mreža podržava glasovne i podatkovne usluge [1:52].

 
2.1.2 Izazovi VoIP-a preko bežične mreže

Iako je VoIP postao vrlo popularan i uspješan u fiksnim sustavima, još uvijek je u ranom stadiju u bežičnim sustavima zbog mnogih tehničkih izazova. U nastavku su navedeni neki od glavnih izazova [1:52-54]:
- Kašnjenje i zastajkivanje – u fiksnom sistemu su kanali obično čisti i end-to-end prijenos može biti ostvaren skoro bez problema, te ne zahtjeva ponovno slanje. Međutim, bežični kanali mogu biti nepovoljni, što rezultira u pogreškama i neispravnim paketima. Paketi bi trebali biti poslani više puta kako bi se osiguralo uspješno primanje, a broj ponovnih slanja ovisi o dinamičkoj radio frekvenciji (RF). Ovo bi moglo rezultirati primjetnim kašnjenjem i varijaciji kašnjenja. Nadalje, za razliku od circuit kanala koji imaju fiksnu propusnost za kontinuirani prijenos, paketni prijenosi su obično poslani „rafalno“ i dijele zajedničke kanale što omogućuje multipleksiranje za učinkovito iskorištavanje kanala.

- Spektralna učinkovitost – u fiksnim VoIP sistemima propusnosti ima i više nego je potrebno te se obično koristi kako bi se smanjilo kašnjenje. Zapravo, circuit-switched prijenosi sa učinkovitom propusnošću su napušteni u korist fleksibilnosti packet-switched prijenosa, iako paketni prijenos donosi dodatne troškove. U bežičnim sistemima spektralni resursi se obično smatraju najskupljim resursima u mreži, te su visoka spektralna učinkovitost od vitalne važnosti za pružatelje usluga. Dakle, bežični VoIP sistemi moraju biti dizajnirani tako da mogu kontrolirati kašnjenje i zastajkivanje bez žrtvovanja spektralne učinkovitosti. Troškovi paketnog prijenosa preko zraka moraju biti svedeni na minimum.
- Mobilno upravljanje - u mnogim HSPD sistemima, mobilno upravljanje je dizajnirano primarno za podatkovne aplikacije. Kad se mobilni korisnici kreću između stanica, procedura prespajanja sljedi prekini-prije-nego-spojiš princip. Ovo vodi do velike prijenosne rupe kad se uređaj prebacuje s jedne stanice na drugu. Iako je prijenosna rupa uglavnom prihvatljiva za podatkovne aplikacije to nije slučaj za glasovni prijenos. Kako bi podržao VoIP aplikacije, prijelazni dizajn mora biti optimiziran tako da se prijenosna rupa minimizira i ne utječe na kontinuiranost govora.

- Prijenosna snaga i pokrivenost – uz dodatne pakete je potrebna veća snaga za prijenos iste količine glasovnih podataka, što rezultira manjom pokrivenosti. Uz to, „rafalni“ paketni prijenos isto zahtjeva veću količinu snage te na trenutke degradira performanse u vanjskim dijelovima podrčja pokrivena mrežom. Dakle, više naprednih tehnika mora biti usvojeno kako bi se nadoknadili nedostatci.

2.1.3 3G/4G HSPD

Dva dominantna tijela koja dominiraju bežičnim mobilnim standardima diljem svijeta su 3GGP i 3GPP2, koji su proizveli svoje standarde treće generacije: UMTS terrestrial radio access (UTRA) i CDMA2000. Četvra generacija, nazvana long-term evolution (LTE) i ultra mobile broadband (UMB), su trenutno u procesu standardizacije. Tehnologije korištene u oba standarda su poprilično slične, pa će se tako primjeri u ovome poglavlju bazirati na 3GPP2 [1:53].
Na 3G strani, CDMA2000 standard uključuje dvije komponente: 3G1x, fokusiran na circuit switched glasovne usluge i CDMA2000 evolution data optimized (EVDO) standard posvećen brzim podatkovim uslugama. Fokus če biti na EVDO [1:53].
Dizajn EVDO zračnog sučelja donosi dinamičku time division multiplexing (TDM) strukturu na prednjem linku sa malom vremenskom strukturom (600 puta u sekundi) kako bi osigurao brzo i fleksibilno raspoređivanje paketa. Kako bi se poboljšala učinkovitost prijenosa pod dinamičkim RF uvjetima, hybrid automatic repeat request (HARQ) tehnika je upotrebljena sa inkrementalnim smanjenjem. U EVDO Revision0 definirano je 12 nominalnih brzina prijenosa raspona od 38.4kbps do 2.4Mbps. Planer na base transceiver station (BTS) odlučuje koji će korisnikovi paketi biti poslani u svakom otvorenom terminu te paket mora biti prenesen sa odgovarajućom brzinom prijenosa traženom od terminala [1:53].
Na reverse linku, dizajn EVDO Rev0 je sličan 3G1x. CDMA tehnologija je korištena za prijenos podataka i za istovremeni rezultat poslanosti. Svaki korisnik može prenositi pakete u svakom trenutku brzinama između 9.6kbps i 153kbps. Trajanje svakog paketa je 16 vremenskih dijelova. Reverse brzine prijenosa podataka su pod zajedničkom kontrolom mobitela i BTS-a na distribuirani način. BTS prati ukupnu razinu smetnji i emitira informacije o preopterećenju putem kontrolnih kanala na forward linku. Informacije koristi svaki mobitel kako bi prilagodio reverse promet gore ili dolje, ovisno o dostupnoj snazi. Dok nema prijenosa nikakvih paketa, reverse kanal je ugašen, dok pilot i drugi kanali kontinuirano prijenose [1:53].
U EVDO RevisionA forward brzine su definirane do 3.1Mbps, koje su dodatno proširene do 4.9Mbps od strane EVDO RevisionB. BTS ima fleksibilnost prenošenja na bilo kojoj brzini zatraženoj od terminala [1:54].
Reverse link operacija su značajno unaprijeđene u EVDO RevA. Definirano je dvanaest veličina kodiranih paketa sa efektivnom brzinom prijenosa između 4.8kbps i 1.8Mbps. HARQ tehnika se koristi do četiri prijenosa: svaki prijenos ili podpaket traje četiri vremenska dijela. Reverse kontrola brzine prijenosa podatka se obavlja sveobuhvatnom upravljačkom shemom koja prilagođava dozvoljenu snagu terminala, što na kraju određuje brzinu koja može biti postignuta [1:54].
Osim poboljšanja kanala, EVDO RevA specificira QoS okvir koji omogućuje radio access network (RAN) da razlikuje aplikacije s različitim QoS očekivanjima. Na zračnom sučelju, forward link primjenjuje različite prioritete i uvjete za tok podataka sa različitim QOS zahtjevima bilo preko više korisnika ili jednog istog korisnika. Reverse resursna shema upravljanja omogućuje multipleksiranje podataka iz drukčijih tokova koji dijele iste fizičke kanale, te tokovi QoS zahtjevi se uzimaju u obzir kao bi se odredila distrubucija resursa [1:54].
UMB je evolucija tehnologije 1x EVDO. To je četvrta generacija (4G) brzog širikopojanog sustava razvijenog od 3GPP2. Radi na mnogo većoj propusnosti, u rasponu od 1.25MHz do 20MHz te koristi orthogonal frequency division multiple access (OFDMA) tehnologiju i za forward i reverse link prijenose. OFDMA ima prednosti nad CDMA u nekoliko aspekata. OFDM prijenosni simbol traje mnogo duže nego CDMA te tako ne zahtjeva tako strogu vremensku sinkronizaciju između odašiljača i prijemnika. U usporedbi sa CDMA, ortogonalni prijenos između OFDMA podnosioca poboljšava reverse link performanse, te eliminira smetnje unutar stanice. RF prijenos može biti zakazan u vremenu isto kao i u frekvencijskoj dimenziji, te tako poboljšati učinkovitost raspoređivanja [1:54].
U UMB-u je propusnost nosioca podijeljena na podnosioce sa razmakom od 9.6kbps. Osnovna prijenosna jedinica je definirana kao pločica koja se sastoji od 16 podnosioca u frekvenciji i 8 OFDM simbola u vremenu koje traje oko 1ms, ovisno o duljini cikličkog prefiksa konfiguracije. Svaka pločica može isporučiti podatke brzinom između 75kbps i 630kbps pod različitim kombinacijama kodiranja i modulacija. Do 6 HARQ prijenosa je dozvoljeno po paketu, što pomaže pri iskorištavanju vremenske raznolikosti. Kod nositelja sa 5MHz ovo vodi do širokog raspona brzina: od 0.4Mbps do 17Mbps. Nadalje, UMB standard specificira više vrsta naprednih tehnologija antena koje mogu poboljšati spektralnu učinkovitost, te uključuju [1:54-55]:
- Multiple input multiple output (MIMO) tehnologiju, gdje se više tokova podataka prenose prema i od jednog korisnika istovremeno pomoguću više antena za prijenost i primanje. Ovisno o konfiguraciji antene, MIMO može povećati spektralnu učinkovitost dva ili četiri puta. Sa MIMO-om, korisnikova brzina se povećala na 35Mbps sa 2x2 konfiguracijom antena i na 65Mbps sa 4x4 konfiguracijom.
- Spatial diversity multiple access (SDMA) , gdje BTS istovremeno šalje tokove podataka različitim korisnicima koristeći istu frekvenciju.

OFDMA se koristi u UMB-u i za forward i reverse link prijenose. Ortogonalna priroda OFDMA značajno pospješuje spektralnu učinkovitost reverse linka u usporedbi sa EVDO baziranim na CDMA. Međutim, da bi se optimizirala mobilna upravljivost, UMB koristi hibridnu CDMA + OFDMA strukturu na reverse linku. CDMA i OFDMA prijenosi održavaju odvoje pilote [1:55].

2.2 Tehnike za poboljšanje efikasnosti VoIP prijenosa

Zbog ograničene propusnosti preko zračnog sučelja, govorni kodek korišten u ćelijskim sistemima je obično u kategoriji uskih, nisko-bitnih glasovnih kodiranja. U CDMA2000 sistemima, enhanced variable rate codec (EVRC) se koristi kako bi kako bi generirao glasovne okvire svakih 20ms. Postoje četiri različite vrste definiranja okvira u EVRC; full rate: 171 bit (ekvivalent 8.55 kvps) , ½ rate: 80 bita (4kbps), ¼ rate: 40 bita (2kbps) i 1/8 rate : 16 bita (0.8kbps). ¼ se zapravo ne koristi kod EVRC glasovnog kodiranja. Postotak okvira sa svake stope varira ovisno o strukturi i aktivnosti govora. EVRC koder se široko koristi u 3G1x mrežama [1:55].
Nedavno je novi kodek EVRC-B standardiziran i implementiran kao kodek sljedeće generacije za CDMA2000 mreže u 3GPP2. Glavna dizajnerska odluka za EVRC-B je da osigura dobar odnos između kapaciteta i kvalitete. EVRC-B koristi sva četiri okvira nabrojana ranije. Definira osam načina rada [1:55].



Slika 8 : prosjecne stope za različite modove
Slika 8 ([1:56]) prikazuje procjene prosječnih izvornih stopa za različite modove. Mode0 EVRC-B , kao i EVRC , ne koristi 1/4. Ima sličnu brziu prijenosa podataka kao EVRC, ali nije kompatibilan sa EVRC i u globalu nudi bolju kvalitetu glasa nego EVRC. Drugi modovi imaju manje brzine prijenosa podataka te tako postupno pogoršavaju kvalitetu glasa. Mode7 EVRC-B koristi jedino ¼ i 1/8. Različiti modovi osiguravaju mehanizam za pružatelje usluga kako bi dinamički prilagodili glasovni kapacitet i kvalitetu u njihovoj mreži [1:56].
Među različitim brzinama prijenosa podataka, 1/8 okviri obično predstavljaju pozadinske smetnje tijekom tihih razdoblja te tijekom govornih rupa tijekom razgovora. Oni ne nose nikakve stvarne signale govora te time imaju minimalan utjecaj na primljenu kvalitetu glasa. Dakle, većina 1/8 okvira može biti odbačena i ne biti poslana. Samo mali dio 1/8 okvira je poslan kako bi se koristio u rekonstrukciji što prirodnijih pozadinskih smetnji. Ova tehnika se naziva tiha detekcija i suzbijanje te uvelike poboljšavaju učinkovitost prijenosa glasa preko zračnog sučelja eliminacijom velikog dijela paketa koji sadrže 1/8 okvire [1:56].

2.2.1 Kompresija zaglavlja

Kompresija zaglavlja radi tako da iskorištava redundandnosti u zaglavlju, je neophodna za pružanje troškovno učinkovite VoIP usluge u bežičnoj mreži. VoIP paketi se obično prenose preko RTP/UDP/IP protokola. Nekompresirano zaglavlje je oko 40 bytova po paketu. U punom EVRC okviru od 22 bytea, RTP/UDP/IP zaglavlje nadoda više od 180% na glasovnu informaciju. Bez kompresije bi postalo dominantno i imalo utjecaja na kapacitet zračnog sučelja. Ova polja mogu biti klasificirana u više kategorija [1:56]:
- Statička ili poznata polja koja ne moraju biti poslana sa svakim paketom. Na primjer, izvorišna i odredišna adresa u IP zaglavlju, izvorišni i destinacijski port u UDP zaglavlju.

- Zaključena polja koja mogu biti zaključena od drugih polja te tako ne moraju biti slani sa svakim paketom; na primjer vremenska oznaka u RTP zaglavlju koja se konstantno povećava.

- Promjena polja koja mogu biti poslana u kompresiranom obliku kako bi se čuvala propusnost.



Slika 9 : klasifikacija zaglavlja polja u RTP/UDP/IP zaglavljima

Kompresija i suzbijanje zaglavlja su navedeni u oba standarda, 3GPP i 3GPP2. Najpopularnija shema kompresije se naziva robust header compression (ROHC). ROHC protokol specificira nekoliko operativnih modova u kojima svaki zahtjeva drukčiji nivo povratnih informacija. Odabir moda ovisi o tipu komunikacijskog kanala između kompresora i dekompresora. Sa ROHC kompresijom, RTP/UDP/IP zaglavlja su reducirana sa 40 na 1-4 byta. Nadalje, ROHC dizajn je također otporan na pogreške paketa što ga čini prigodnim za korištenje u bežičnim prijenosima. Kao rezultat, ROHC uvelike poboljšava prijenosnu učinkovitost VoIP paketa preko zračnog sučelja [1:57].
Trebalo bi biti naglašeno da se ROHC tipično ne koristi kao end-to-end kompresijska shema, jer je potpuno IP zaglavlje potrebno kako bi se informacija mogla propisno usmjeriti. Tipična implementacija ROHC-a je prikazana na Slika 10. ROHC kompresor i dekompresor su smješteni u mobilnom uređaju i mrežnom kontroleru (RNC) ili packet data service node (PDSN) [1:57].

2.3 Tehnike za podršku VoIP-a u EVDO RevA i RevB

Kao što je prije spomenuto, EVDO RevA i RevB standardi su poboljšani kako bi podržali QoS aplikacije kao VoIP. Konkretno, mala veličina i usmjereno simetrična priroda VoIP prometa se nije dobro slagala sa prometnim pretpostavkama u originalnom dizajnu EVDO Rev0 [1:57].



Slika 10 : implementacija ROHC arhitekture

Kao rezultat toga dodane su nove značajke posebno prilagođene za poboljšanje VoIP performansi i kapaciteta [1:58].

2.3.1. QoS izvršenje u EVDO RevA/RevB

Kad se VoIP usluga pomiješa sa općenitim prijenosom podataka preko istog zračnog sučelja odmah dođe u pitanje QoS. Originalni EVDO dizajn je bio fokusiran na pružanje osnovnih podatkovnih usluga te nije imao podršku za QoS mehanizme. Svi podatci prema i od korisnika su bili pomiješani te ih se nije moglo razlikovati. EVDO RevA je uveo klasificiranje raznih aplikacija usmjerenih na različite korisnike ili čak na istog korisnika [1:58].
EVDO RevA i RevB dopuštaju korisniku da otvori više tokova preko istog zračnog sučelja te multipleksiraju promet iz drugih tokova na isti fizički kanal. Zaglavlje radio link paketa identificira tok kojem paket pripada, tako da mobilni uređaji i RAN mogu ispravno tretirati paket. Za VoIP usluge, QoS izvršenje je fokusirano na ubrzano dostavljanje paketa. Stoga je VoIP paketima obično dodijeljen veći prioritet nego ostalim paketima. Specifični pristup na zračnom sučelju se razlikuje za forward i reverse link [1:58].
Na forward linku planer zračnog sučelja je centralni dio koji procjenjuje prioritet paketa i kontrolira prijenos za sve korisnike sektora. Specifični algoritam raspoređivanja QoS-a korišten u BTS je tipično ovisan o proizvođaču opreme, dok učestalo korišteni uključuju [1:58] :
- QoS zahtjeve za tok kao što su latencija paketa i zahtjevi u slučaju gubitka paketa
- Performanse toka
- Podatci zaostataka toka
- Dinamično RF stanje mobilnog korisnika
- Poštenje prema ostalim tokovima drugih korisnika sa sličnim QoS zahtjevima.
Budući da je cilj QoS izvršenja zadovoljiti performanse toka bez obzira na korisnikovo RF stanje to često vodi do konflikta sa RF učinkovitosti optimizacije, a planerov posao je da pronađe ravnotežu između dva cilja [1:59].
Na reverse linku je predviđeno QoS izvršenje preko reverse prometnog kanala MAX (RTMAC) protokol. RTCMAC protokol podržava više slojeva MAC toga koji odgovaraju toku drugih aplikacija. Svaki MAC tok može biti konfiguriran kao high capacity (HiCap) ili low latency (LoLat) tok. LoLat tok uvijek ima prijenosni prioritet veći od HiCap toka. LoLat tok obično ima povećanu snagu kako bi se smanjila latencija kod prijenosa. Iako LoLcat ima veći prioritet od HiCap-a oboje mogu biti multipleksirani na istom fizičkom nivou [1:59].

2.3.2 Učinkoviti dizajn formata paketa za VoIP

VoIP paketi su puno manji u usporedbi sa tipičnim paketima Internet aplikacija. Na primjer, EVRC koder generira 22 bytni glasovni okvir svakih 20ms. Koristeći tehnike kompresiranja navedene ranije, VoIP paket predstavljen RAN-u je uglavnom veličine oko 26 byte-ova. Kako bi se tako mali paketi poslali uspješno preko zračnog sučelja, EVDO RevA definira novi format RLP paketa koji omogućava da se ROHC kompresirani paketi smješten savršeno u RL fizički paket veličine 256bita bez pretjeranog segmentiranja [1:59].
Na forward linku se koristi drukčija tehnika kako bi se poboljšala učinkovitost VoIP prijenosa. U originalnom dizajnu fizički paket je nosio informaciju usmjerenu prema samo jednom korisniku. Kako bi podržao VoIP promet potrebno je značajno povećanje fizičkog paketa što vodi do loše RF učinkovitosti. EVDO forward link je podijeljen u 600 vremenskih dijelova te bi mogao početi ozbiljno opterećivati resurse ako bi svaki put nosio paket za samo jednog korisnika. Kako bi prevladali ove probleme, EVDO RevA definira novi format MAC paketa na forward linku, multiuser packet (MUP), gdje se osam RLP paketa od različitih korisnika mogu multipleksirati u jedan fizički paket. Ovo ne samo da pospješuje prijenos paketa već i oslobađa resurse [1:59].

2.3.3. Ubrzavanje dostave VoIP paketa unutar EVDO RevA/RevB RAN

Osim QoS izvršenja koje omogućuje EVDO RevA/RevB RAN da ubrzaju isporuku VoIP paketa, postoje određene tehnike koje se koriste kod dostave paketa kako bi se slagale sa karakteristikama VoIP prometa [1:60].
VoIP paketi su veličine 20ms, tako da ih je poželjno dostavljati svakih 20ms odnosno 12 vremenskih dijelova. HARQ operacija na EVDO RevA/RevB reverse linku dopušta do četiri podpaketna prijenosa, što uzima 16 vremenskih dijelova. Kako bi prilagodili VoIP zahtjevima predstavlja se prekidanje koje kontrolira koliki broj podpaketa koji se treba poslati da bi se zadovoljilo packet error rate (PER). U VoIP toku je to postavljeno na tri, sa 1% PER-om [1:60].
Osim zračnog sučelja, EVDO RevA/RevB omogućuju slanje RLP paketa nasumično kako bi se smanjilo kašnjenje. Ovo pomaže optimizaciji performansi VoIP aplikacija [1:60].

2.3.4 Glatka mobilna podrška

Jedan od glavnih izazova kod podrške VoIP-a za mobilne mreže je osiguravanje kontinuiteta usluga korisnicima kad se kreću unutar mreže. EVDO podržava meko prespajanje u reverse linku kao dio CDMA operacija te tako osiguravaju glatko prebacivanje korisnika iz ćelije u ćeliju [1:60].



Slika 11 : VoIP prijenosna vremenska linija u EVDO RevA



Slika 12 : Vremenska linija prijelaza poslužujućeg sektora u EVDO RevA/RevB
Na forward linku EVDO radi u simpleks načinu rada, pri čemu terminal komunicira samo sa jednim sektorom u bilo kojem trenutku. Ako terminal otkrije jači signal iz drugog sektora mijenja naznaku sektora na data rate control-u (DRC) te se odmah prebacuje na taj sektor kako bi primio pakete [1:61].
U cilju smanjenja rupe između promjene sektora EVDO RevA uvodi novi kanal data source control (DSC) koji je posvećen prespajanju. Terminal označava BTS poslužitelja na DSC kanalu. Kad terminal utvrdi da treba promijeniti BTS to ukazuje na DSC kanalu te nastavlja pokazivati na DRC kanal unaprijed definirano vrijeme. Ovo dopušta pravilno prespajanje [1:61].

2.4 Tehnike i performanse VoIP-a u UMB-u

Za razliku od EVDO-a, podrška za multimedijske aplikacije, uključujući VoIP, je svojstveni dio UMB standarda. Mnoge tehnike su specificirane kako bi optimizirale VoIP preko zračnog sučelja [1:63].

2.4.1 Jedinica alokacija resursa

U UMB-u jedinica alokacija resursa za paketni prijenos je pločica koja se sastoji od skupina od 16 potencijalnih prenosioca za jedan okvir. Svaki prenosioc zauzima propusnost od 9.6kbps te svaki okvir traje 1ms. Računica prikazuje da u nosiocu 5MHz može biti smješteno 1000 VoIP korisnika [1:63].

2.4.2 Fleksibilno trajanje RL okvira

U cilju poboljšanja učinkovitosti RF prijenosa, UMB kao i EVDO koristi HARQ na forward i reverse linkovima. HARQ proces se sastoji od šest prijenosa od kojih svaki traje jedno trajanje okvira. Za VoIP aplikacije je neophodna kontinuirana mrežna pokrivenost i pouzdan prijenos paketa. Zbog ograničene snage unutar mobilnog terminala, pod lošim RF uvjetima reverse link performanse mogu postati problem. Kako bi se nosio s ovim, UMB dizajnira poseban set formata paketa koji koriste proširene strukture okvira gdje HARQ šalje tri okvira umjesto jednog. Ovo smanjuje snagu na 1/3 za istu količinu informacija te uvelike poboljšava mrežnu pokrivenost [1:63].

2.4.3 Minimiziranje signalizacijskog preopterećenja

U UMB-u prijenosi preko zračnog sučelja određuje BTS planer. Određeni korisnik se obavještava kada će biti njegov red za primanje podataka. Za aplikacije kod kojih se mogu tolerirati visoke latencije i velika zastajkivanja odluke mogu biti bazirane na svakom pojedinom paketu. VoIP ima striktnije zahtjeve u vezi kašnjenja te je tako VoIP promet sastavljen od malih ali učestalih paketa. Ako za svaki paket mora biti izričito predviđeno kada će stići to može dovesti do pretjerano velike signalizacije te tako smanjiti ukupnu razinu RF performansi. Ako paketi pristižu periodično tijekom razgovora korisnije je unaprijed dodijeliti niz RF resursa korisniku dokle god se RF stanje značajno ne mijenja. Ovo je ideja iza zadatka specificiranog u UMB-u. Odluke su kategorizirane u [1:63]:
- Ne-konstantni zadatak – koristi se kod prijenosa jednog paketa
- Konstantni zadatak – odnosi se na sve pakete osim ako nije drukčije definirano. Dobar je za VoIP jer prepoznaje uzorke pristiglih paketa.

2.4.4 Potpuna mobilna podrška za VoIP

UMB mobilni terminal i dalje održava aktivni skup s mrežom kao i CDMA sustav. Aktivni skup označava set sektora koji odašilju jak signal prema mobitelu. Terminal prenosi CDMA pilot i neke povratne informacije aktivnom setu u dediciranom CDMA kontrolnom segmentu. Ugrađene CDMA operacije omogućuju terminalu komunikaciju sa više BTS-ova te odlučuje koja RF konekcija ima najbolju kvalitetu za podatkovne komunikacije. Terminal prima pakete iz samo jednog sektora unutar aktivnog skupa, to jest forward link serving sector (FLSS) i terminal odašilju pakete samo jednom sektoru unutar aktivnog seta nazvanog reverse link serving sector (RLSS). Tipično su FLSS i RLSS sektori sa najkvalitetnijim forward i reverse kanalima. U bilo kojem trenutku FLSS i RLSS mogu biti isti ili različiti ako se dogodi primjetna neravnoteža. Kada se korisnik pomiče preko različitih ćelija ili sektora FLSS i RLSS se isto tako moraju promijeniti kako bi se slagali sa korisnikovim novim RF uvjetima. Ako je korisnik angažiran u aktivnom VoIP pozivu tijekom ovog perioda, proces promjene FLSS-a i RLSS-a mora biti napravljen tako brzo da se ne ošteti kontinuiranost govora [1:64].
U UMB-u terminal određuje željeni FLSS bazirano na snazi signala forward pilot svakog sektora u aktivnom setu, te željeni RLSS bazirano na kvaliteti reverse pilot-a. Kako prijenos paketa na forward linku zahtijeva povratnu informaciju od reverse linka, i obrnuto, novi sektor koji radi u jednom smjeru mora imati prihvatljivu kvalitetu u drugom smjeru kako bi mogao slati povratne informacije. Zbog toga UMB specificira sljedeći kriterij za promjenu sektora [1:65]:
- Kvaliteta reverse pilota naznačena od strane FLSS-a ne smije biti manja od najbolje kvalitete reverse pilota naznačenoj od strane aktivnog skupa. U tom slučaju, terminal mora pronaći drugi DFLSS koji je u skladu sa ovim zahtjevima. Pravilo se odnosi na RLSS kao i na DRLSS.
Nakon što terminal odredi novi posluživački sektor, šalje naznaku prijelaza tome sektoru. U međuvremenu svi kanali s povratnim informacijama i dalje komuniciraju sa poslužnim sektorom, tako da može posluživati dok se ne obavi prijelaz. Kad novi sektor vidi naznaku prijelaza zajedno sa postojećim sektorom obavi prijelaz toka podataka za korisnika. Kada je spreman poslužiti korisnika obavijesti mobitel na forward kanalu. Tada mobitel prebaci slanje podataka na novi sektor. Slika 13 ([1:65]) prikazuje taj proces [1:65].



Slika 13 : EVDO RevB reverse kanali sa DTX operacijom

[Wozniak jR.]

3.1 Što je Quality of Service

Quality of Service (QoS) je pojam ovisan o kontekstu koji izražava kvalitativne mjere usluga za korisnike. U ovome poglavlju, QoS je definiran kao sposobnost osiguranja resursa i usluga na IP mreži. Osiguranje resursa je opredjeljenje mreže kako bi zadovoljila određene zahtjeve aplikacije, kao što su propusnost, gubitak paketa i kašnjenje. Razlikovanje usluge je mogućnost mreže da postupa s različitim paketima na različite načine. QoS za VoIP je obično opisan u uvjetima pružanja usluga i kvaliteti glasa. Kvaliteta usluge je povezana sa dostupnošću, kašnjenjem nakon završetka poziva (post-dial delay) i količina uspješno završenih poziva. Kvaliteta poziva je korisnikovo iskustvo [1:121].
QoS je obično mjerena u VoIP-u sa dvije jedinice: razumljivost i kašnjenje. Razumljivost je numerička prezentacija percipirane kvalitete glasa nakon kompresija i/ili slanja te je izražena u jednoj od dvije metode. Prva je bazirana na International Telecommunications Union Standardization Sector (ITU-T) standardima P.800 i P.862. Izražavaju razumljivost kao broj između 1 i 5, s tim da je 5 optimalni (nije moguć). P.862 koristi usporedbu izlaznog kodiranog signala i primljenog kodiranog signala. To znači da testni uređaji definiraju uzorak glasa prije nego testiranje započne. Pošiljatelj pošalje digitalnu verziju uzorka glasa te je primatelj usporedi sa originalnim uzorkom. U ovome modelu se kašnjenje ne uzima u obzir [1:122].
Bolji model mjerenja kvalitete VoIP poziva je baziran na E-Model-u opisanome u ITU-T G.107 i G.108 gdje se kvaliteta izražava kao R faktor s rasponom između 1 i 100 baziranih na više mrežnih i instrumentalnih oštećenja koji su snimljeni pomoću pasivnih tehnika. E-Model je originalno usmjeren prema VoIP okruženju za planiranje VoIP prijenosa. Međutim, mnogi proizvođači su usvojili E-Model za pružanje mjera kvalitete glasa u Call Detail Records (CDRs) za snimanje kvalitete i provođenje analizi. MOS je šire korištena QoS mjera zbog upoznatosti telekomunikacijske zajednice sa značenjem MOS brojeva. Slika 14prikazuje usporedbu razine zadovoljstva korisnika i MOS broja definiranog po ITU-T P.800 i G.109 standardima [1:122].



Slika 14 : usporedba zadovoljstva korisnika
Osim MOS mjerenja, drugi faktor koji utječe na iskustvo korisnika je kašnjenje.
ITU-T Y.1291 označava tri dijela koji su odgovorni za QoS : kontrolni, podatkovni i upravljački dio. Kontrolni dio je povezan s mehanizmima za kontroliranje toka podataka u sistemu, korišteći call admission control (CAC), usmjeravanje (routing) ili mehanizme za ograničavanje protoka. Podatkovni dio je usmjeren na utjecanje na pojedine pakete uz pomoć upravljanja spremnika, označavanje paketa, čekanjem i raspoređivanjem, klasifikacijom prometa i uvjetovanjem prometa. Upravljački dio je fokusiran na operacije, administracije i upravljanje koristeći usluge na razini dogovora i preuređenjem prometa [1:122].

3.2 Zašto je QoS potreban

U doba dial-up modema korisnici nisu imali pristup brzim Internet konekcijama. Čak i današnje doba brzog interneta, IP konekcije su ograničene propusnošću zbog limita infrastrukture. Problem je u tome što su mreže dizajnirane za podatkovne aplikacije koje idu preko transmission control protocol-a (TCP) i njihove izvođenje nije toliko uvjetovano kašnjenjem i gubitkom paketa kao VoIP. Čak se ni uz pravilno dizajniranu mrežu ne mogu spriječiti neočekivana zagušenja. U vrijeme gužvi, QoS služi kako bi se osigurala prihvatljiva razina usluge za VoIP korisnike [1:123].

3.3 Faktori koji utječu na QoS

MOS rezultat ovisi o brojnim nedostatcima. Izvori nedostataka ovise o tehnologiji. Kod VoIP-a govorimo o zastajkivanju, jeki, kompresiji govora i gubitku paketa. Kada govorimo o zastajkivanju mislimo na razliku u kašnjenju u mjerenom intervalu. Svi VoIP instrumenti su dizajnirani kako bi kompenzirali zastajkivanje [1:123].
Drugi faktor je jeka. Jeka je definirana kao odzvanjanje govornikovog glasa u njegov slušni kanal te se tako reproducira na obje strane. Prvi prikaz jeke je kada govornik čuje vlastite riječi nakon kratkog vremena od kad je to izrekao. Međutim, ako je razmak između kojeg je korisnik nešto rekao i to ponovno čuo manji od 25ms, ljudski mozak kompenzira za jeku te ona onda nije primjetna. Ova vrsta jeke se obično naziva popratni ton. Drugi prikaz jeke je percipirana jeka, te se događa kada je kašnjenje povratnog signala veće od 25ms [1:124].
Većina problema vraćanja glasa je uzrokovana u analognom dijelu krajnjeg uređaja. Drugi uzrok je akustična jeka, odnosno jeka zbog slabe izolacije između mikrofona i zvučnika. Jeka postaje sve više ometajuća što je glasnija te je tipično izražena kao talker echo loudness rating (TELR) i za VoIP telefone je tipično između 62dB i 65dB za razgovore s malim kašnjenjem [1:124].
Treći faktor koji utječe na MOS je prouzročen od kompresije govora. Kada govorimo o kompresiji govora mislimo na kodiranje bazirano na predviđanju radi smanjenja potrebnih bitova kako bi se glas prenio. Nedostatak prouzročen kompresijom govora se obično naziva faktor nedostatka opreme (Ie) te je uzrokovan distorzijom glasa prilikom kompresije [1:124].



Slika 15 : usporedba atributa kodeka

Ie vrijednost za G.711 koji ne koristi kompresiju je 0. Ie vrijednost se obično povećava proporcionalno nivou kompresije (iako novi kodeci kompenziraju kako bi smanjili Ie). Slika 15 ([1:125] pokazuje usporedbu nekih atributa par kodeka [1:125].
Efekt distorzije je primjetniji kako se kašnjenje povećava. Primjer, MOS 4.0 je moguć za G.711 kad je kašnjenje manje od 250ms, no za G.729A samo kad je manje od 125ms [1:125].
Zadnji faktor koji utječe na MOS je gubitak paketa. Mjeri se kao omjer paketa koji su uspješno poslani i broja paketa poslanih tijekom mjerenog vremena, te se izražava u postotcima. Ako uspoređujemo sa TDM, VoIP tolerira gubitak paketa. U TDM-u, gubitak paketa se manifestirao kao error bit te je rezultirao kao smetnja koja je smanjivala MOS. U VoIP-u, gubitak paketa je rezultat izgubljenog, oštećenog ili odbačenog glasovnog uzorka. Mnogi razgovori uključuju vrijeme kada se sluša samo tišina ili samo jedan govornik govori. Tijekom toga vremena, teško je zaključiti koliki je gubitak paketa. Očito je da gubitak paketa postaje primjetan tek kada slušamo sugovornika. Kako bi kompenziralo za gubitak paketa, jedan način je da se ponovno pošalje izgubljeni paket, a drugi da se koristi forward error correction (FEC). Obje tehnike se nazivaju packet loss concealment (PLC). Rezultat je taj da slušatelj neće primijetiti gubitak osim ako se ne izgubi više paketa male veličine, tipa 10-20ms [1:125].
Drugi razlog je taj da je vjerovatnost da će se izgubiti više slijednih paketa jako malena. Primjera radi, 2% gubita paketa će rezultirati da će dva uzorka biti izgubljena u sekundi govora (10ms je jedan paket). Vjerojatnost da će se izgubiti 2 slijedna paketa je jako malena. Pošto krajnji instrumenti prave korekcije za prvi paket i kako je to samo 10ms, većina slušatelja to neće ni primijetiti, osim ako nisu u tihoj sobi. S korištenjem PLC i prirodne distribucije izgubljenih paketa, testiranje je pokazalo da prosječni slušatelj ne primjećuje gubitak paketa dok nisu oko 3%-5% [1:125].
Kao što je već rečeno, kašnjenje je jedna od dvije mjere koje se koriste za QoS. Većina VoIP sistema je dizajnirana kako bi izbjegli „raspravljanje“. „Raspravljanje“ je stanje koje se dogodi kada jedna osoba počne pričati u isto vrijeme kad i druga no nije to primijetila zbog većeg kašnjenja. „Raspravljanje“ je lakše primijetiti kod internacionalnih poziva i kod poziva preko satelitskih mreža. Kod normalnih razgovora postoji pauza između trenutka kad jedna osoba prestane pričati i druga započne te iznositi otprilike 200ms. Ovaj fenomen se naziva „preuzimanje-reda“ te kad se kašnjenje približi „preuzimanju-reda“ dogodi se gubljenje paketa u sinkronizaciji i rezultira „raspravljanjem“. U VoIP-u, „raspravljanje“ se obično događa oko 220ms, ovisno o osobi [1:126].
Uz problem sa „raspravljanjem“, duže pauze mogu promijeniti značenje rečenice. Izvori koji uzrokuju end-to-end VoIP kašnjenje su prikazani na Slika 16 te tri izvora kašnjenja na koje telekom inženjeri utječu su kodek, spremnik protiv zastajkivanja te sklopna kašnjenja [1:126].
Većina QoS standarda dostupnih danas su bazirani na zastajkivanju, kompresiji glasa, jeki, gubitku paketa i latenciji end-to-end TDM sistema. Ovi standardi su sporo prihvaćeni za VoIP te je rezultat toga da je većina SLA-ova i VoIP-a konzervativni u odnosu na TDM mjerenja vrijednosti umjesto VoIP mjerenja [1:126].
Uz to, većina SLA-ova osiguranih od provajdera su fokusirani na podatkovne aplikacije i mjerni intervali su često u prosjeku 30-tak dana, mjereni na mrežnom sloju i koriste jako mali dio mjernih točaka. Tipični poziv se smatra prekinutim ako je gubitak paketa 100% kroz interval od 6-10s te s tim 30-to dnevno mjerenje može imati veliki broj razdoblja sa neprihvatljivim performansama. Mjerenje na mrežnom sloju ignorira kašnjenje i gubitak paketa iznad mrežnog sloja, kao što su kodeci i spremišta protiv zastajkivanja. Konačno, ograničavanjem mjerenja na određeni broj putova rezultira neprimijećene degradacije između čvorova koji nisu mjerne točke [1:126].



Slika 16 : izvori kašnjenja

3.4 QoS mehanizmi

Kao što je već spomenuto, postoje 3 različita pristupa kako bi postigli QoS za VoIP, a zovu se kontrolni, podatkovni i upravljački pristup. Budući da je ovo poglavlje fokusirano na glasovne aspekte kvalitete QoS-a, kontrolni i podatkovni pristup će biti objašnjeni, bez upravljačkog. U raspravi o mehanizmima je potrebno razlikovati mehanizme koji se trenutno koriste i one koji će postati upotrebljavani u budućnosti [1:127].

3.4.1. Trenutni kontrolni QoS mehanizmi

Prva rasprava se fokusira na upravljački dio koji se bavi upravljanjem tokova paketa kroz mrežu. Mehanizam korišten danas od strane telekom inženjera kako bi osigurali kontrolni QoS su prometni inženjering, CAC, multiprotocol label switching i QoS rutiranje. Prvi zahtjev svih komercijalnih pristupa koji koriste kontrolni QoS je provesti ispravan inženjering nad prometom. Tipično, prometno inženjerstvo uključuje pretvaranje DS0-sa u IP. Pretvorbeni faktor ovisi o kodeku, IP verziji i intervalima uzoraka. IP kalkulacija prometa treba uključivati IP overhead i korisničke signalne pakete. Jednostavna metoda pretvorbe je pomnožiti postojeći DS0 sa pretvorbenim faktorom. Detaljnija metoda koristi uključuje sat s najvećim zauzećem (Busy Hour Erlang B). Primjera, ako se pretpostavi da je sat s najvećim zauzećem 25, spojni pristup bi trebao biti s raspodjelom od 2.5Mbps za VoIP promet uključujući signalizaciju, kao što je prikazano [1:127].



Slika 17 : izračun propusnosti

Sljedeći zahtjev za kontrolni pristup je korištene CAC-a kako bi se osiguralo da opterećenje ostane unutar projektiranog opterećenja prometa. CAC je funkcija koju se može pronaći u call control agentu (CCA) , Softswitch-u ili local session controller (LSC), koji su IP ekvivalenti današnjih krajnjih ureda. CAC je tipično naveden u uvjetu broja poziva ili proračuna. Na primjer, CAC brojač poziva vrijednosti 10 znači da će CAC blokirati sve zahtjeve za pozivom nakon što ima 10 aktivnih poziva. Proračunski CAC koristi bin-packing algoritam koristeći prave zahtjeve propusnosti za svaki poziv ovisno o korištenom kodeku. Na primjer, ako je CAC proračun 1Mbps, CAC može dozvoliti 11 G.711 (20ms uzorak) poziva ili 30 G.729 poziva ili kombinaciju oba kodeka tako da zbroj bude manji od 1Mbps [1:127].
Drugi kontrolni QoS mehanizam je QoS rutiranje koje kontrolira put kojim protok ide. Na primjer, premium korisnici mogu biti prespojeni na direktni put između dvije točke dok normalni korisnici mogu ići „okolnim putem“ kako bi se izbjeglo zagušenje. Ovi putovi mogu biti polu-optimalni jer uključuju više kašnjenja iako zadovoljava QoS zahtjeve [1:128].
Završni kontrolni mehanizam je korištenje MPLS-a kako bi se osigurao QoS. U postojećim VoIP mrežama, MPLS se primarno koristi kako za logičko razdvajanje prometa, brzo popravljanje kvarova te kako bi minimizirao prespojno kašnjenje unutar jezgre mreže. Ponekad su poslužitelji primorani logički razdvojiti promet te MPLS virtualne privatne mreže omogućavaju poslužiteljima da ispune taj cilj. U ovom slučaju, korištenje Ipsec-a za kriptiranje VPN-a nije uvijek najbolje implementirano zbog smanjenja performansi kriptiranjem. Još jedna upotreba MPLS-a je za popravak end-to-end konekcijskih problema. Većina proizvođača koji podržavaju MPLS na svojim platformama tvrde da je FFR manji od 50ms. Iako je oporavak od kvara primjetan za VoIP korisnika, poziv će i dalje ostati aktivan. Finalna prednost MPLS-a je to da smanjuje end-to-end kašnjenje sa label switchingom. Važno je uzeti u obzir da je MPLS-Traffic Engineering (MPLS-TE) značajka MPLS-a, ali značajka obično nije tipično asocirana sa VoIP QoS-om na bazi toka, nego može biti primijenjena na skupnoj osnovi za poboljšanje performansi [1:127].

3.4.2 Trenutni podatkovni QoS mehanizam

Drugi pristup je podatkovi pristup i fokusiran je na pružanje QoS-a na bazi paketa. Mehanizmi korišteni od strane podatkovnog mehanizma uključuju uvjetovanje prometa, diferencirane usluge (DiffServ) i per hop behaviors (PHB). U kombinaciji sa CAC, uvjetovanje prometa je provedeno na IP sloju kako bi osiguralo da VoIP opterećenje unutar prometnih granica. Uvjetovanje prometa je opisano u RFC 2475, ali za ovu svrhu je fokusirano na mjerenje i oblikovanje [1:128].
U zakrčenim mrežama je potrebno praviti razliku između VoIP paketa i ostalih paketa kako bi se VoIP paketima osigurao povlašteni tretman. Metoda korištena od strane komercijalnih proizvođača je da u zaglavlje VoIP paketa označe polje, te se naziva differentiated service field (DS Field). DS Field ima šest bitno polje (omogućava 64 moguće postavke) unutar IP zaglavlja. Jednom kad je paket označen, oznaka se naziva differentiated services code point (DSCP). Uobičajeno je DSCP označen od strane zadnjeg instrumenta ili prvog LAN preklopnika na koji dođe VoIP paket. Naravno, signalizirajući, noseći i upravljački paketi su označeni s drukčijim DSCP-om [1:127].
Kao što je prethodno spomenuto, DSCP-ovi su postavljeni tako da PHB-ovi mogu biti primijenjeni. PHB-ovi mogu biti specificirani u smislu njihovih resursa (npr. spremnika, širine pojasa), prioritetom u odnosu na druge PHB-ove ili u smislu njihovih vidljivih prometnih karakteristika (kašnjenje, gubitak paketa i zastajkivanje). U VoIP-u, grupni skupovi su obično segmentirani u nosioca, signalizaciju i mrežno upravljanje. PHB-ovi su tipično povezani sa pristupnim linkom i drugim WAN vezama. No, ako LAN nije ispravno dizajniran i ako se dogodi zakrčenost, PHB-ovi se mogu implementirati u LAN preklopnike kako bi ublažili zakrčenost [1:129].
Iz razloga jer su paketi nosioci osjetljivi na zastajkivanje, gubitak paketa i kašnjenje, primaju ubrzano prosljeđivanje (expedited forwarding – EF) PHB. Primjenom EF PHB-a na VoIP nosiocu će se smanjiti kašnjenje, gubitak paketa i zastajkivanje [1:129].
Za razliku od paketa nositelja, signalizacijski paketi koriste TCP koji tolerira gubitke. Iako je signalizacija otpornija na nedostatke mreže, mora poprimiti željeni PHB kako bi se smanjilo kašnjenje poziva tijekom preopterećenja. Ovisno o proizvođačevim postavkama VoIP signalizacijski paketi mogu primiti EF PHB ili sigurno prosljeđivanje (assured forwarding – AF) PHB. Performanse AF PHB-a ovise o resurcima dodijeljenim AF klasi paketa, trenutnoj opterećenosti AF klase te u slučaju zagušenja klase pad prednosti paketa. Svaki AF PHB ima tri pada prednosti i korisnikovo signaliziranje obično ima najmanju vjerojatnost pada. Ponekad VoIP proizvođači stavljaju kontrolne i signalizacijske paketa u AF odvojeno od ostalog prometa [1:129].
Posljednji grupni skup je mrežno upravljanje. Ovaj skup se normalno sastoji od dva tipa prometa: najveći promet je asociran sa zapisima detalja poziva i Syslog-om; vremenski osjetljiv promet je asociran sa SNMP upozorenjima. Mrežno upravljački promet prima AF PHB te je ponekad najveći promet stavljen u drugi AF nego vremenski osjetljivi promet. Slika 18 pokazuje gdje QoS mehanizmi mogu primijeniti [1:129].



Slika 18 : Trenutni QoS mehanizmi

[Wozniak jR.]

WLAN je jedna od najuspješnijih tehnologija u posljednjih par godina. Koristi se posvuda, od tvrtki, obrazovnih ustanova, aerodroma, domova itd [1:207].
Postoje dvije vrste WLAN arhitekture: Infrastrukturni, koji je najupotrebljavaniji te koristi centralnu stanicu zvanu pristupna točka (AP – access point). Sav promet prolazi kroz AP [1:207].



Slika 19 : Bežična LAN arhitektura

Primjer je prikazan na slici pod A. Ad-hoc nema centralni element te tako treba routing protokol kako bi pružio pouzdanu end-to-end komunikaciju između korisnika. Primjer na slici pod B [1:207].
Najprihvaćenija infrastruktura ad-hoc mreže je bazirana na IEEE 802.11 standardu, koji je u početku bio namijenjen podatkovnim uslugama. Stoga nema idealne karakteristike za real-time komunikaciju preko videa ili glasa. Najuspješnije verzije su IEEE 802.11b i IEEE 802.11g. Glavna razlika je u brzini prijenosa, „b“ ide do 11Mbps dok „g“ ide do 54Mbps [1:208].
Mnogo istraživanja je provedeno kako bi se proširile mogućnosti za real-time komunikaciju preko bežičnih mreža. Kao rezultat toga, razvio se novi standard IEEE 802.11e, koji je razvijen kako bi podržao QoS [1:208].
VoIP svakim danom ima sve veću bazu korisnika. Postoje mnogi programi koji olakšavaju korištenje VoIP-a : Skype, MSN messenger, VoIP cheap itd. Korišteni su svakodnevno jer nude dobru kvalitetu i jeftini su [1:208].
Mnoge tvrtke koriste WLAN kao mrežno rješenje te je zbog toga potrebno istražiti kako se VoIP ponaša preko WLAN-a. Jedno od pitanja je koliko se VoIP poziva može obaviti preko 802.11b? Tri parametra će odgovoriti na ovo pitanje. Prvi parametar je kašnjenje, koje se mjeri u vremenu koje je potrebno da paket stigne s ishodišta na odredište. Maksimalno VoIP kašnjenje je preporučeno od strane ITU-T G.114, te iznosi 150ms. Drugi parametar je zastajkivanje te ono iskazuje promjene u kašnjenju. Mjeri se vrijeme između dolaska paketa. Zadnji parametar je gubitak paketa (LPR – loss packet rate). Ovdje se mjeri koliko je paketa odbačeno u određenom razgovoru. Rezultat LPR-a je dan u postotcima te daje neke naznake o kvaliteti poziva [1:208].

4.1 Simulirani scenarij

4.1.1 VoIP promet

Prije rada na simulaciji karakteristike VoIP prometa moraju biti definirane. Slika 20 ([1:209]) prikazuje najpopularnije kodeke korištene za glas [1:209].



Slika 20 : najčešće značajke kodeka

Za ovu simulaciju je odabran kodek G.711 jer je najrestriktivniji. Ovo će prikazati nagore rezultate te ako se koristi drugi kodek broj VoIP poziva sa dobrom kvalitetom će biti viši od onoga dobivenog u ovoj simulaciji. Mora se naglasiti da u mnogim komercijalnim implementacijama kodek G.711 šalje 160 bytova svakih 20ms. Međutim, u ovoj simulaciji se koriste vrijednosti navedene u tablici. Ove vrijednosti prate standardni PCM kodek (80 bytova svakih 10 ms) [1:209].
Osim toga, treba biti definiran način na koji će VoIP tok raditi preko WLAN-a. U ovoj simulaciji svaki VoIP poziv generira dva VoIP toka u WLAN-u kada se koristi infrastrukturni način. Jedan tok je od krajnjeg čvora do AP, a drugi od AP do drugog krajnjeg čvora. Ovo se događa zato jer je VoIP poziv generiran kao poludupleks promet što znači da samo čvor koji je započeo poziv može prvi slati promet. Nakon toga u neko slučajno vrijeme ovaj čvor prestane te drugi čvor koji je primao podatke počne slati svoj promet. Vrijeme koje svaki čvor ima za slanje prometa je nasumično odabrano. U ad-hoc načinu svaki VoIP poziv generira iz jednog od više tokova ovisno o broju čvorova koji prosljeđuju promet iz izvorišnog čvora prema odredišnom, ali je promet generiran kao i kod infrastrukturnog načina [1:209].

4.2.2 Simulirani scenariji

Simulirano je pet scenarija: tri su bila pod infrastrukturnim načinom arhitekture te dva pod ad-hoc-om. Neki od njih su bili idealni pod čim se misli da su čvorovi u ovim simulacijama bili blizu; to je nešto što se obično u praksi ne događa. Razlog simulacije idealnih uvjeta je kako bi se dobila slika o maksimalnom broju poziva te bi onda taj broj usporedili sa realističnijim scenarijima. Simulirani scenariji [1:210]:
- Idealni scenarij infrastrukturnog načina – AP paketa : 50, 20 čvorova, 1 AP
- Idealni scenarij infrastrukturnog načina – AP paketa : 100 , 20 čvorova, 1 AP
- Realni scenarij infrastrukturnog načina – 20 čvorova , 1 AP (Slika 21)
- Idealni scenarij ad-hoc : 31 čvor
- Realni scenarij ad-hoc : 31 čvor (Slika 22)

Ključna točka u infrastrukturnom načinu rada je AP. Što se više razgovora dodaje, AP mora raspoređivati više prijenosa paketa te če se tako čekanje paketa produljiti. AP ima ograničeni kapacitet te kad se približi tome limitu odbacuje svaki novi primljeni paket [1:210].
Kod ad-hoc-a protokol usmjeravanja mora uspostaviti puteve među čvorovima kako bi se uspostavila komunikacija korisnika. U ovom slučaju će obično biti posrednici u pozivu. Ovisno koji čvorovi razgovaraju, paketi će morati više ili manje skakati kako bi došli do odredišta. Moguće je da se dogodi da jedan čvor postane preopterećen jer sudjeluje u mnogim razgovorima. U tom slučaju će biti kašnjenja i odbacivanja paketa na svim razgovorima koji koriste taj čvor. To je normalno ponašanje u ad-hoc mreži [1:210].



Slika 21 : realni scenarij infrastrukturnog moda



Slika 22 : realni scenarij ad-hoc-a
Međutim, u ovoj simulaciji postoji poseban ad-hoc scenarij koji predstavlja idealne uvjete (čvorovi su blizu). U ovom scenariju neće biti posrednih čvorova jer su čvorovi blizu jedni drugima, te tako paket mora samo preskočiti jednom kako bi došao do odredišta. Stoga, ako postoji veliko kašnjenje to je zato jer je okoliš zasićen te se događa mnogo sudara [1:211].

4.2.3 Značajke simulacije

Koristilo se vrijeme od 100 sekundi za prva četiri scenarija te više od 30 sekundi za posljednji. Ovo vrijeme je dovoljno kako bi dobili željene rezultate [1:211].
U infrastrukturnom načinu rada je dovoljno analizirati samo jedan poziv kako bi se razumjelo što se događa, čak i ako se više poziva odvija u isto vrijeme. Kako je u ovome slučaju centralizirani element AP ne postoji mehanizam za QoS, te tako svi paketi imaju isti tretman. Dakle, ako se AP zasiti, počet će sa odbacivanjem paketa slučajnim odabirom te će to utjecati na sve razgovore koji se odvijaju u isto vrijeme. Znajući ovo, ako jedan razgovor počne davati loše rezultate kašnjenja ili odbacivanja paketa onda će to isto vrijediti i za ostale pozive [1:211].
U četvrtom scenariju je isto tako potrebno pregledati samo jedan poziv kako bi se shvatila situacija. Kako je to savršeni ad-hoc slučaj svi čvorovi su blizu jedni drugima te routing protokol uspostavlja samo jedan skok paketa. Drugim riječima, paketi moraju otići samo od pošiljatelja prema odredištu. Stoga svi razgovori imaju istu okolinu. Dakle ako jedan razgovor pokaže probleme odmah znači da je link preopterećen, te se tako zaključuje da svi razgovori imaju probleme [1:211].
U realnom primjeru ad-hoc scenarija se prikupljaju podatci za svaki VoIP poziv jer svaki poziv ima različit broj preskakanja i drukčiji put. Moguće je da će jedan čvor biti preopterećen i predstavljati probleme dok će drugi raditi sasvim normalno [1:211].

 
4.3 Rezultati

Rezultati su prikazani u par slika. Slika 23 ([1:212]) prikazuje prosječno kašnjenje paketa u odnosu na broj poziva. Slika 24 ([1:213]) prikazuje zastajkivanje u odnosu na količinu poziva. Slika 25 ([1:213]) prikazuje LPR u odnosu na broj poziva. Ovi grafovi prikazuju sve primjere osim realnog ad-hoc scenarija [1:212].
Prvi scenarij pokazuje naglu primjenu kad se doda šesti poziv. LPR se promijeni sa 0% na 10%. Ovo je neprihvatljiva vrijednost jer 10% informacija preko telefona nesmije biti izgubljeno, te zbog toga poziv ne bi bio razumljiv. Isto tako se i kašnjenje poveća na prosjek od 50ms. Zastajkivanje se isto tako povećalo ali ne tako drastično, ali predstavlja uvid da nešto ne radi dobro kao i prije. Ako se doda više poziva parametri postaju sve gori i gori [1:212].
Drugi scenarij je poprilično sličan. Ova simulacija je provedena jer se uvidio neprihvatljivi LPR kod šestog poziva. AP je odbacivao pozive nakon što ga se preoptereti s paketima. Zbog toga mu je uduplana količina koju može primiti. Očekivano je smanjenje LPR-a uz cijenu da će se kašnjenje povećati, te se to i dogodilo. Na šestom pozivu je kašnjenje veće duplo, dakle oko 100ms [1:212].



Slika 23 : prosječno VoIP kašnjenje



Slika 24 : varijacijae u zastajkivanju



Slika 25 : gubitak paketa

Ovo je neprihvatljiva vrijednost jer će većinu vremena paketi kasniti više od 150ms kako bi dobili prosječnu vrijednost od 100ms. Međutim, nije se dogodilo manje odbacivanje paketa. Rezultat LPR-a je 9% umjesto 10%. Zastajkivanje je ostalo isto kao i prije, nakon šestog poziva se počelo pogoršavati. Opet isto, vrlo loši rezultati nakon šestog poziva [1:212].
Treći scenarij je realna infrastruktura. U ovom slučaju su čvorovi locirani oko AP, kao što se to događa u većini praktičnih slučajeva. Međutim, rezultati su slični kao i prijašnjim idealnim uvjetima. Opet se nakon šestog poziva kvaliteta pogoršava do neprihvatljivosti. Preciznije, prosječno kašnjenje je oko 100ms, LPR je malo niži nego u prijašnjim slučajevima ali je opet neprihvatljivo visok sa svojih 7%. Zastajkivanje se ponaša kao u prijašnjim slučajevima. Kad dodamo 7,8,9 i 10 poziv kao u prva dva scenarija rezultati postaju stvarno loši [1:214].
Rezultati za idealne scenarije ad-hoc-a su isto tako prikazani u Slika 23 , Slika 24 i Slika 25. U ovome slučaju ključan dio je dodavanje jedanaestog poziva. Kašnjenje i zastajkivanje prikazuju neprihvatljive vrijednosti. Prosječno kašnjenje je oko 100ms a zastajkivanje ima nagli skok između desetog i jedanaestog poziva. LPR pokazuje skok sa 0% na 0.3%, što je bitna promjena. Kako u idealnom slučaju paketi trebaju skočiti samo jedanput kako bi stigli do odredišta, te se onda pojavi odbacivanje paketa zaključuje se da u originalnom čvoru 50 paketa čeka na slanje. Dakle, ovaj niski LPR objašnjava zašto je tako veliko kašnjenje. Zaključak je da se jedanaest ili više poziva nemože odvijati u idealnom ad-hoc scenariju [1:214].
Nisu prikazani zbrojeni rezultati realnog ad-hoc scenarija jer su drukčiji u svakoj simulaciji. Ovisi o tome koji pozivi su aktivni te koji čvorovi sudjeluju u tim pozivima. Kako bi objasnili ovo Slika 26 ([1:214]) prikazuje mjerenje trenutnog kašnjenja svakog paketa u scenariju te prikazuje rezultate dva poziva preko četiri ćelije, sa slabim kašnjenjem [1:214].



Slika 26 : realni ad-hoc scenarij s četiri poziva

Kašnjenje paketa je veće od 50ms većinu vremena u ova dva poziva, sa skokovima i iznad 150ms. Međutim, pronađen je scenarij u kojem se sedam poziva može voditi istovremeno. U ovome scenariju, kašnjenje paketa je uvijek ispod 40ms i većinu vremena ispod 20ms za sedam poziva, što je prihvatljiva vrijednost [1:214].
Odrađeni su i drugi scenariji te je utvrđeno da su scenariji sa četiri poziva prihvatljivi, dok su oni sa sedam neprihvatljivi. U nijednoj simulaciji nije pronađeno da osam poziva može raditi ispravno. Iz ovih rezultata se može uvidjeti da se ne može izvući generalni zaključak koliko je poziva moguće u ad-hoc-u jer taj broj ovisi o čvorovima koji sudjeluju u razgovoru i kojim putem podatci idu. Pronađeni su čak scenariji gdje ni jedan poziv nije uspješno izvršen jer routing protokol nije pronašao dobar put između pozivatelja i primatelja [1:215].

4.4 Statistička analiza

Pokušano je pronaći da li postoje neki obrasci po kojima se kašnjenje i zastajkivanje dešavaju. Na ovaj način bi mogli samo pogledati distribuciju određenog VoIP poziva i zaključiti da li je kvaliteta razgovora dobra ili loša. Zbog toga su napravljeni histogrami sa postotkom paketa u omjeru sa vremenom. Za kašnjenje i zastajkivanje možemo pogledati Slika 27 ([1:215]) i Slika 28 ([1:216]) [1:215].



Slika 27: distribucija kašnjenja. Grafovi predstavljaju realni infrastrukturni model



Slika 28: Evolucija zastajkivanja. Grafovi predstavljaju realni infrastrukturni model

Slika 27a prikazuje simulaciju sa dobrim parametrima, a distribucija koja opisuje ovu situaciju je eksponencijalna u kašnjenju paketa jer većina paketa ima malo kašnjenje. Naravno, ne počinje na nuli jer je nemoguće da paket ima kašnjenje 0ms. Minimum se nalazi oko jedne ili dvije ms. Ako se doda više poziva i prouči neprihvatljivi slučaj sa šest poziva vidi se kako distribucija ima vrhunac na niskim vrijednostima kašnjenja, što uključuje oko 30% paketa. No postoji i bitan postotak paketa sa visokim kašnjenjem, između 100 i 200ms. Izgled ove distribucije podsjeća na slovo „U“. Ako se doda još poziva, polako će nestajati kašnjenje u malim vrijednostima te se povećavati unutar visokih. U ovom trenutku distribucija se može vidjeti normalna distribucija, kao što je prikazano na Slika 27c [1:215].
Drukčije se razvija situacija kod zastajkivanja. Sa pet poziva je distribucija centrirana oko 10ms, kao što je prikazano na Slika 28a. Ovo je očekivani rezultat kad je zastajkivanje predstavlja dobar rezultat. U slučaju sa šest poziva na Slika 28b, kada se kvaliteta poziva smanji, red na desnoj strani je duži i distribucija predstavlja nesimetričan oblik. Sa osam poziva, prikazanih na Slika 28c, se ponaša eksponencijalno. Počinje u niskim vrijednostima i onda ide u vrlo dug desni red. Pošto je bitan faktor zastajkivanja varijacija, očito je da je ona najveća kad je u pitanju puno poziva. Graf sa pet poziva prikazuje najnižu varijaciju [1:216].
Sa ovom statičkom analizom može biti postavljen zanimljiv uzorak. Gledajući na distribuciju paketa kroz kašnjenje i zastajkivanje za jedan razgovor možemo utvrditi što će se približno dogoditi, te da li će razgovori imati dobru ili lošu kvalitetu tako da usporedimo distribucije s nekim od prijašnje navedenih uzorak [1:215].

4.5 Testiranja i 802.11e

4.5.1 Podloga za testiranje

Obavljeno je mnogo istraživanja u području VoIP-a preko WLAN-a. Posebno, u nekim istraživanjima je korišten pravi testbed kako bi se mjerile performanse VoIP-a preko WLAN-a.Pitanje je, koliko je poziva moguće obaviti preko 802.11b? Istraživanja poput onog navedenog dolje su pružila odgovor koristeći prave mjere [1:216].
Garg i Kappes su postavili eksperimentalne uvjete sa osam bežičnih klijenata povezanih ja jedan AP. AP je bio spojen na Ethernet LAN mrežu. U ovoj LAN mreži se nalazilo osam računala koji su služili kao krajnje točke za VoIP komunikaciju. Klijenti u WLAN-u su bili postavljeni u istu sobu bez prepreka. Očito je ovaj scenarij drukčiji od onoga navedenog u prijašnjoj simulaciji no broj VoIP tokova unutar WLAN-a će biti isti, dva VoIP toka po VoIP komunikaciji. Međutim, ovaj testbed je drukčiji jer postoji žičani dio. U svakom slučaju, ovaj scenarij je sličan infrastrukturnom modu u prijašnjoj simulaciji [1:216].
Po završetku eksperimenta, prvih pet poziva je imalo dobru kvalitetu. Kada se uspostavio šesti poziv povećalo se vrijeme obilaska paketa, no kvaliteta komunikacije još nije pala. Međutim, kada se uspostavio sedmi poziv svi razgovori su osjetili osjetan pad kvalitete [1:217].
Rezultati su prilično slični prijašnjoj simulaciji. U oba slučaja se kvaliteta pogoršala oko sedmog poziva [1:217].



Glavni rezultati analitičkog modela [1:217]:
- Kada se koriste kodeci G.729 ili G.723 broj poziva koji se može uspostaviti je veći nego kada se koristi G.711.
- Ako se koristi drukčija vrsta standarda, u ovom slučaju 802.11a sa 54Mbps brzinom, može se uspostaviti više poziva nego koristeći 11Mbps.
- Ako su intervalni okvir i veličina svakog paketa veći, onda se šalju veći fragmenti unutar svakog paketa te se broj uspješnih poziva povećava.

4.5.2 VoIP preko 802.11e

Zbog nedostatka mehanizama za pružanje QoS unutar standarda 802.11a/b/g, IEEE definira proširenje koje bi tim standardima trebalo omogućiti mehanizme za pružanje QoS. Ovo je standard 802.11e. Glavna razlika između 802.11e i prijašnjih standarda je u tome da su prijašnji davali fiksne vrijednosti uključenih parametara, dok su u 802.11e četiri parametra koja su podesiva [1:217]:
- AIFS - vrijeme koje kanal mora biti postavljen u stanje mirovanja prije nego počne s prijenosom. U prijašnjem standardu je bilo fiksno vrijeme ; DIFS.

- Contention Window minimum (CWmin) i Contention Window maximum (CWmax) - ako je u nekom trenu kanal zauzet, stanica će započeti sa periodom povlačenja. Period povlačenja je broj mjesta koje treba čekati prije nego se započne novi prijenos. Broj mjesta je definiran jednolikom distribucijom u intervalu [0,CW].

- Tx Opportunity (TXOP) - Jednom kad stanica dobije pristup kanalu, dobije odobrenje za slanje unutar vremena koje odredi TXOP parametar. Ako je ovaj parametar postavljen na 0, bit će dopušteno poslati samo jedan paket u tom trenu.

Dakle, gledajući u prethodne parametre lako je za shvatiti da se podešavanjem različitih parametara u svakoj pojedinoj stanici može osigurati QoS. Možemo dati veći prioritet slanju smanjivanjem AIFS-a ili izjednačavanjem CWmax= CWmin. Ovi parametri se ne mogu mijenjati unutar 802.11a/b/g jer su fiksni [1:218].
Provedeno je mnogo istraživanja nad 802.11e kako bi se pronašla optimalna konfiguracija za određene ciljeve. Korišten je eksperiment kako bi se usporedila poboljšanja koja je donio 802.11e nad 802.11b. Ponovno se koristio kodek G.711 te 80 bytni paketi generirani svakih 10ms. U ovom slučaju, promet se generirao sa alatom iperf. Kako bi razvili testbed promet je generiran kao što je prikazano na Slika 29. Ograničenja koja su postavljena: 50ms kašnjenja u jednom smjeru i maksimalni gubitak paketa 5% [1:218].
S ovim uvjetima bi se moglo uspostaviti osam VoIP poziva preko standarda 802.11b. Ono što je ovaj eksperiment pokušao je dobiti optimalnu konfiguraciju za podesive parametre u cilju poboljšanja VoIP poziva preko WLAN-a [1:218].



Slika 29 : testbed generator prometa

Sličan zaključak bi mogao biti proveden i u idealnom ad-hoc scenariju, kada su čvorovi vrlo blizu. U ovom slučaju je uspostavljeno 10 poziva istovremeno bez problema. Kada je dodan jedanaesti poziv kašnjenje i zastajkivanje su se povećavali dok nisu došli do nedopustivih razina. U ovom trenu LPR nije bio 0%. Bio je niskih 0.3%, no i to je bitno jer objašnjava zašto je kašnjenje bilo tako visoko [1:219].
Nema zaključaka u slučaju realnog ad-hoc scenarija. Razlog je to što se svaka simulacija ponašala drukčije. U realnom ad-hoc scenariju je vrlo bitno koji čvorovi započinju razgovor te preko kojih čvorova informacije teku [1:219].
Pokazana je mreža gdje sedam poziva može biti uspješno uspostavljeno, te druga situacija gdje su četiri poziva imala lošu kvalitetu. Nije pronađena nijedna simulacija u kojoj je uspostavljeno osam poziva bez problema [1:219].
Konačno, IEEE 802.11e standard je uveden kako bi se pružio QoS. Pokazano je kako je nadmašio rezultate dobivene sa 802.11b. Konkretno, prema ovim testiranjima poboljšanje ide od 8 do 11 poziva [1:219].

[Wozniak jR.]

5. VoIP SIGURNOST

Ovo poglavlje započinje sa analizom zašto VoIP-u raste popularnost i kako se nosi sa sigurnosnim prijetnjama zbog vlastitih protokolnih karakteristika i tipa mreže preko koje šalje podatke. Sigurnosne prijetnje su klasificirane i promatrane pod CIA-inim modelom koji naglašava tajnost, cjelovitost i dostupnost. Kada se prijetnje analiziraju na individualnoj razini, strategije koje se već koriste za slične probleme mogu biti primijenjene za ublažavanje prijetnji. Međutim, skup različitih protokola koje koristi VoIP i modularnost VoIP sustava sugeriraju da je potreban end-to-end pristup za rješavanje kompleksnih sigurnosnih problema. Bitnije, IP mreža koja se koristi za prijenos VoIP poziva je najčešće Internet, koji se prostire preko mnogih zemalja i nadležnosti. Vatrozidi i ostali mehanizmi nisu direktno dostupni administratoru [1:364].

5.1.1 Obrazloženje za korištenje VoIP-a

Danas je Web glavni medij preko kojeg tvrtke vode svoje poslove. Očito je da je Web natjerao mnoge tvrtke da reorganiziraju svoje poslovne strategije i strukture korištenjem prilagodljivih Internet tehnologija kako bi ostale konkurentne u poslovnom svijetu. VoIP tehnologija sve više privlači pozornost i interes u industriji. Brojne VoIP aplikacije nude sve značajke (pozivateljev ID, pozive na čekanju itd) na tradicionalnim Private Branch eXchange (PBX) rješenjima [1:364].
Brojne tvrtke se prebacuju na VoIP jer na trenutnoj infrastrukturi mogu prenositi i glasovne i obične podatke. Smanjuju se troškovi održavanja, cijene poziva i ostali troškovi vezani sa običnim telefonskim mrežama [1:364].
5.1.1 VoIP protokoli

U principu, VoIP tehnologije upotrebljavaju skupine protokola, koji uključuju signalizacijske protokole poput session initiation protocol (SIP), kontrolu podataka i prijenosne protokole kao što su transmission control protocol (TCP), real-time transport protocol (RTP), user diagram protocol (UDP) i Internet Protocol (IP) [1:365].

5.1.2 Uljezi u tradicionalnim telefonskim i VoIP mrežama

Uljezi su poznati kao osobe koje stekle neovlašteni pristup FBX ili sustavu govorne pošte te koristiti besplatne pozive. Neke studije pokazuju da se upadi događaju radi osvete, sabotaže, ucjene ili pohlepe [1:365].

Uljez također može presresti pozive, provaliti u nečiju osobnu glasovnu poštu ili vidjeti povjerljive razgovore. Jedan pravi slučaj je kad se hacker ubacio u VoIP tvrtke Sublet Software u Americi. Tvrtka je dobila poprilično velik račun na kojem su se vidjeli međudržavni pozivi [1:365].
5.1.3 Napadi na IP mreže

VoIP je ranjiv na mrežne napade kao što je maliciozni kod (virusi, trojanci, crvi), DoS, DDoS i slično. Ovi napadi oštećuju sisteme tako da obuzimaju resurse, onemogućavaju prave korisnike, kompromitiraju povjerljive informacije i oštećuju kodove i podatke. Svi sistemi spojeni na Internet su osjetljivi na maliciozni kod koji pokušava zaraziti što je moguće vise računala [1:365].

5.1.4 VoIP zahtjeva end-to-end sigurnosni model

VoIP sigurnost se susreće sa kompleksnijim problemima u odnosu na tradicionalne mreže, jer se VoIP mreže sastoje od više komponenti te svaka od tih komponenti ima svoje sigurnosne prijetnje [1:366].
Dakle, svaka mreža koja podržava VoIP mora biti dizajnirana, implementirana i upravljana na sigurni način, pružajući end-to-end sigurnost između VoIP aplikacija. Iako mnoge industrijske i istraživačke organizacije rješavaju ovaj problem u kontekstu zaštite real-time transport protocol-a (SRTP) i IPSec-a, još uvijek ne postoji jedinstvena sigurnosna politika koja specificira i regulira kako mehanizmima treba osigurati VoIP aplikacije [1:366].
Gledajući veličinu Interneta, upravljanje se najbolje postiže kroz distribuirane metode, gdje je svaka mreža kontrolirana prema unaprijed definiranim pravilima jer je globalnu implementaciju posebnih sigurnosnih pravila nemoguće provesti [1:366].

 
5.2 Ranjivost VoIP protokola

5.2.1 Sigurnosni problemi SIP-a

Session initiation protocol (SIP) je real-time signalizacijski protokol za IP govor koji je razvijen od strane Internet Engineering Task Force. Korišten je za dvosmjerno komuniciranje u kojem poruke izmjenjuju dva ili više čvora. SIP je odgovoran za osnovne komunikacijske zadatke kao što su uspostava poziva, signaliziranje za pokretanje poziva, ton za biranje i završetak poziva. SIP je također odgovoran za druga signaliziranja kao što su pozivateljev ID, prebacivanje poziva i čekanje. Ponaša se kao Signaling System 7 (SS7) protokol korišten u standardnoj telefoniji i H.323 koji se koristi u IP. To je protokol na razini aplikacija te se stoga može koristiti iznad drugih protokola. Može biti prenesen preko UDP, TCP ili SCTP. Ako se prenosi preko UDP-a, povećana mu je brzina i učinkovitost [1:366].
TCP se koristi u sigurnosne svrhe, kada su potrebni secure socket layer / transport layer security (SSL / TLS). Stream control transmission protocol (SCTP) ima veću otposnost na DoS napade kroz four-way handshake metodu. SCTP može koristiti dodane sigurnosne servise preko „TLS preko SCTP“ ili „ SCTP preko IPSec“ [1:366].
SIP se sastoji od različitih komponenata, uključujući user agent (UA), poslužitelja preusmjeravanja, registarski poslužitelj, lokacijski server i proxy server. UA software uključuje klijentske i serverske komponente. Odlazni pozivi su na strani klijenta, dok su dolazni na strani servera. Nakon procesiranja i prebacivanja, usmjeravanje prometa će obaviti proxy server. Ovjeravanjem zahtjeva se baci registarski server, a poslužitelj preusmjeravanja je odgovoran za informacije za UA klijente. UA klijenti šalju zahtjev UA serveru za uspostavu poziva. Korisnik obavještava registarski server o njegovoj trenutnoj lokaciji kako bi se dopustilo komuniciranje [1:366].
Kao što se da primijetiti, temelj tradicionalnog sustava (PBX) je zamijenjen sa IP glasovnim serverima koji se obično vrte na Linux ili Microsoft operacijskim sustavima. Serveri koji pružaju VoIP usluge te bilježe pozive su veoma osjetljivi na napade malicioznog softwarea i hakiranje [1:366].
SIP protokol koristi jednostavni set poruka kao što su invite, ack, options, cancel, bye i register. UA klijent koji želi započeti sesiju šalje invite. Na tu poruku dobije odgovor OK te nakon toga ACK poruku. Ako se želi prekinuti konekcija, salje se Bye. Cancel prekida pozivnicu na čekanju. Kako bi promijenili neke parametre sesije, koristi se Options [1:367].
VoIP-specifični protokoli su glavni izvor ranjivosti. SIP je tekstualno kodiran što ga čini lakim za analizu sa alatima kao što su Perl ili lex. SIP promet je obični tekst u svojoj osnovnoj formi. Glasovni promet je ranjiv na pregledavanje paketa (traži se pozivateljev ID ili lozinka) te omogućava napadaču krivotvorenje paketa za manipulaciju uređajem i stanjem poziva. Na primjer, ovakva vrsta manipulacije može rezultirati u prijevremenom prekidanju i preusmjeravanju poziva. Isto tako je jednostavno presresti nekriptirane pozive. Hakeri mogu skinuti besplatni software s Interneta i presresti pozive bez problema. Kako bi se zaštitio identitet pozivatelja i njegove informacije, SIP promet mora biti kriptiran. Iako se do sad pokušavalo pronaći dobar način kriptiranja, za sad nijedan univerzalno usvojen [1:367].
Postoje napadi specifični za VoIP signalizacijske protokole, uključuji SIP. Jedan od ovih napada se naziva Bye napad. Cilj Bye napada je prekidanje komunikacija prijevremeno, što se može razmatrati kao DoS napad [1:367].
SIP protokol se ne koristi samo kod VoIP-a, već i kod instant messaginga (dopisivanja). Napadač može manipulirati porukama te slati lažne poruke jednom korisniku te ga uvjeriti da je to poslao drugi korisnik s kojim razgovara [1:367].

5.2.2 Sigurnosni nedostatci H.323

H.323 je International Telecommunication Union (ITU) standard za zvučne i video komunikacije preko mreže. H.323 uključuje nekoliko protokola kao što su H.225, H.245 itd. Svaki od ovih protokola ima svoju zadaću u procesu poziva. H.323 mreža obično uključuje gateway, gatekeeper-a, multipoint control unit (MCU) i back end service (BES). Gateway se ponaša kao most između H.323 mreže i vanjske ne-H.323 mreže kao što su SIP ili PSTN. Gateway podržava kontrolu protočnosti. Gatekeeper je opcionalan i odgovoran je za optimizaciju mrežnih zadaća. U slučaju prisutnosti gatekeepera, BES može postojati za potporu funkcija kao što su dozvole, usluge i konfiguracije. MCU je isto opcionalna komponenta H.323 mreže [1:367].
H.323 promet je uvijek usmjeren kroz dinamičke portove što predstavlja problem za firewall-ove koji nisu namijenjeni za VoIP. Dakle, potrebno je koristiti firewall namijenjen za VoIP. Još jedan ozbiljan problem H.323 mreže je network address translation (NAT) jer vanjska IP adresa ne odgovara portu navedenom u zaglavlju H.323, IP adresi i portu korištenom unutar mreže. Tako ispravne adrese i brojevi porta moraju biti poslani na krajnje točke kako bi se uspostavio poziv. U usporedbi sa H.323, SIP je fleksibilnije rješenje, jednostavnije i jednostavnije za implementaciju. SIP je isto tako prikladniji za potporu inteligentnih korisnikovih uređaja, kao i za implementaciju naprednijih opcija [1:368].

5.2.3 Sigurnosni nedostatci RTP-a

Real-time transport protocol, standardni protokol koji je dizajniran za real-time prijenos podataka, nudi end-to-end prijenos podataka sa real-time karakteristikama. RTP nudi obilježavanje, praćenje dostavljenosti i korisnu nosivost. VoIP promet se prenosi kao RTP paket. RTP se izvršava nad UDP-om [1:368].
Nakon signalizacije, RTP je odgovoran za prenošenje glasovnih paketa. Nažalost, RTP ne garantira QoS za real-time usluge, umjesto toga se RTP oslanja na servise nižih razina [1:368].
RTP napad je baziran na ranjivosti u prijenosu medija. Napadač može poslati RTP paket sa lažnim paketom, što znači da su zaglavlje i korisna nosivost napunjeni slučajnim brojevima. Ovaj napad može smanjiti kvalitetu glasa te srušiti korisnikovo računalo. Jedan pristup kako se zaštiti od ovoga je da se provjeravaju sljedovi brojeva u RTP paketima. Ako je slijed neujednačen smatra se napadom [1:368].

5.3 Druge vrste VoIP napada i nesigurnosti

5.3.1 Spam preko VoIP-a

Isto kao i mail, VoIP je osjetljiv na spam (isto zvan spam-over-internet telephony (SPIT)), SPIT može biti smatran kao prijetnja botnet-ova, koji mogu onemogućiti VoIP sistem. Ako VoIP korisnik prima puno spam poziva svaki dan, to bi ga moglo odbiti od korištenja VoIP-a [1:372].
SPIT je još gori od spama. Ako primamo mailove sa kašnjenjem od par minuta to čak i nije toliki problem, dok je SPIT vidljiv za krajnjeg korisnika tako da pogađa gateway i degradira kvalitetu poziva. SPIT može pogoditi bilo koji IP-bazirani telefonski sistem. Kako bi se nosili sa SPIT problemom, par tvrtki je razvilo rješenje za takve prijetnje. Tehnike za borbu protiv SPIT-a uključuju filtriranje, dozvole i pozivateljevu reputaciju, no sve postaju manje efektivne kako SPIT metode postaju pametnije [1:372].

5.3.2 Dynamic Host Configuration Protocol (DHCP)

DHCP napadi se odnose na maliciozno računalo na mreži koje može slati prekomjerene zahtjeve na DHCP server te prisiliti server da izda sve raspoložive IP adrese. Kako je mnogo mjesta na mreži sa dinamičkom konfiguracijom, uljez ima puno ranjivih točaka na raspolaganju. Tako DHCP server ne bi mogao procesirati ispravni zahtjev te bi to zaustavilo nove uređaje pri pristupanju mreži. Dalje, maliciozna VoIP aplikacija može odgovoriti DHCP zahtjevima te im dati krive informacije. Ovo može prouzročiti DoS ili omogućiti man-in-the-middle napad. Kako bi obuzdali ovaj napad, VoIP aplikacije mogu osigurati mehanizam sigurnosti kako bi se vratili na početnu konfiguraciju za dodjelu adresa i isto tako mogu provjeriti DHCP odgovor kako bi se uvjerile da je ispravan. U ekstremnim situacijama, predlaže se statičko postavljanje IP adresa [1:373].

5.3.3 DoS – Denial of Service

DoS napadi uvijek upućuju na sprječavanje pristupa mreži tako da se „bombardira“ server, proxy server ili voice-gateway server sa malicioznim podatcima. DoS uzrokuje problem kod kojeg korisnik ne može koristiti servise ili usluge koje normalno očekuju da su na raspolaganju. Uljezi mogu pokrenuti cijeli spektar DoS napada protiv VoIP aplikacije i njenih protokola [1:370].
 

[vision19]

Što se mene tiče sticky, radim diplomski gdje ima dosta VoIP-a i jedva čekam vremena uhvatiti i sve pročitati do kraja Odlično!