Az LTE maghfllozal monitorozisinak kihiv6sai 6s megotdisai Vnncn Pnl Budapesti Mfrszaki 6s Gazdasdgtudomdnyi Egyetem, Tdvkdzl1si 6s MddiainformatikaiTansz1k
[email protected]
Szelrruor GRaoR,
Srv GAson, Cseszxo EruoRr
AITIA International Zrt. {szelindi, gsey, ecseszko}@aitia.ai
Kulcsszavak: forgalmi analizis,
LTE,
EPC,
l0
Gbitls Ethernet, hetozatmlnitorozes, rcljes1neny-mutat1k
A kotsze{i csomagkapcsolt mobil maghiildzat kiil6nf6le leilesztdsei az LTE maghdtrfzatiiban mind megjetennek: fj inteddszek, fi protokollok,iihil6zall elemek. Ezek a vdltozdsok a hiil6zat-monitorozdsi megoldaisok feld is (j kihiviisokat taimasztanak. A Yesztesdgmentes Gsomag-elkapds ds a nanoszekundum nagysigrendii id6pecsdtel6s a maghdldzatban megjelen6 10 Gbivs sebessdgii kapcsolatokon c6lhardver haszndtatdt ig6nyti.
A monitorozdsi architektrlra mellett ebben a cikkben
olyan forgalom-analitikai megold6sokat is bemutatunk, amelyekkel lefedhet6k az fjonnan megjeten6 oper6tori ig6nyek is. A korszer[i mobil magh6l6zatok hibaok-analizise gyakran csak a krilonf6te hibdkra jeltemz6 diat6gus-param6terek elemz6s6vel v6gezhet6 el. irdsunkban ettekintjrik azokat a protokoll-mintazatokat, amelyek vizsg6lat6val a legfontosabb kapcsol6d6si, mobilit6s-menedzsmenthez kothetS, nagy v6taszid6ket okoz6, vagy az adatforgalmaz6si k6pess6gek csokken6s6ben megmutatkoz6 hib6k kiszrirhet6k. Mindezeken til osszefoglaljuk a vizsg6latok legfontosabb m616sz6mainak (KPls; Key Performance lndicators) kinyer6-
si m6djait is.
1. Bevezet6s
rlzenetek egyedi id6pecs6tel6s6t. Az itt felmenj16, lehets69es monitoroz6si akad6lyok lektjzdhet6ek, de ehhez alaposan fel kell t6rk6pezntjnk a h6l6zati kapcsolatok tfpusait, a szdllit6si, alagutaz6, adapt6ci6s 6s applik6ci6s protokollokat, ezek rizeneteit 6s param6tereit. A v ez{rl6iizenete k ki6 rt6 ke l6se so riin kti o nose n f o ntos I
megismerni azt, hogy egy hibarizenet onmag6ban mit jelent(het), 6s milyen hat6sa van (vagy lehet) az tjzenetet kiv6lt6 okoknak a szolg6ltat6s min6s6g6re. A protokolldial6gusok sikeress6gi ardnyai atapj6n Kpl-ket 6rdemes defini6lni; ezek ktisz6b6rt6k-6tl6p6sei lesznek az
esetleges hib6k egyik els6 indik6torai. A kovetkez6kben az EPC monitoroziis6nak kdvetelm6nyeit 6s kihfv6sait tekintjrjk dt, majd roviden bemutatjuk az LTE rendszer-elemeinek logikai kapcsol6d6s6t 6s az elemek legfontosabb funkci6it. A 4. szakaszban az EPC saj6toss6gaib6t ad6d6 teggyakoribb h6t6zati hibalehet6s6geket vesszr-ik sorra, 6s bemutatjuk azokat a jellegzetes mint6kat, amelyek ismeret6ben ezek a monitoroz6s sor6n intelligens m6don kiszfirhet6k, v6grjl a jelz6srjzenetekb6l 6s a felhaszn616i forgalomb6l kinyerhet6 legfontosabb teljesitm6nymutat6k sz6rmaztat6s6t mutatjuk be.
A mobilh6l6zati architektrir6ban mind a r6di6s hozz6f6r6si hiil6zatban, mind pedig a magh6l6zatban is jetent6s vSltoz6sokat hozott azLfE (Long Term Evolution). Az EPC (Evolved Packet Core) eserny6je alatt a csomagkapcsolt magh616zat ktilonf6le fejleszt6sei szerepelnek: [j interf6szek, rij protokollok, rij hAt6zati etemek jetentek meg. Ennek koszdnhet6en a h6l6zatmonitoroz6s sor6n rlj kihiv6soknak kell megfetelni. A kor6bbi fetadattfpu- 2. Az, LTE EPC monitoroz6s sajitossegai sokhoz k6pest az oper6tori oldalon megjelent a felhaszn5l6i adatfolyamok vizsgdlat6nak ig6nye is. A tegm6- A t6vkozl6si jelz6shAl6zat monitoroz6si feladatai a kolyebb vizsg6latokat ezeken az adatokon is off-line v6g- zcis csatorn6s jelz6srendszerek (pl. Signaling System 7) zik, Am az adatok el6feldolgoz6sa, folyamszintrj rekor- 90-es 6vek kozep6n indult elterjed6se 6ta alapjaiban dokba rendez6se, a vez6rl6si (p6ld6ul mobilit6smenedzskeveset veltoztak. A berendez6sek kommunik6ci6s sement) 6s felhaszn6l6i inform6ci6k (pl. forgatmi statiszti- bessdgei ugyan folyamatosan n6vekedtek, de mivel a kdk) korrel6ci6ja a monitoroz6 rendszer menet k6zben, jelz6sh6l6zat 6ltal kezelendd 0zenetek sz6ma 6s voluon-the-fly v6grehajtott feladatai koz6 tartoznak. mene nagys6grendileg nem v6ltozott, az interf6sz-seAz EPC kapcsolatai a mai gyakorlatban m6r trilnyo- bess6gek novel6s6vel ez kdvethet5 maradt. m6 tobbs6gben Ethernet felett jonnek l6tre 6s lp-alapf Az LTE EPC komponensei m6r szinte kiz6r6lag csak ak. A monitoroz6si architekt0r6nak tov6bbra is biztosi- Etherneten kommunik6lnak. Ez a k6zeg a t6vk6zl6si tania kell a vesztes6gmentes csomag-elkap6st, 6s az magh6l6zatban viszonylag fjnak sz6mft alig f6l 6vti-
36
lrurorou zo12 - LXVI. EVFoLvAM,2012
Az LTE maghAlozat monitorozAsdnak kihiv6sai zede kezdtek el tdmegesen 6t6llni erre. A migr6ci6 sor6n a t6vk0zl6sben megszokott, konnyen kdvethet6 pontpont kapcsol6ssal mrikdd6 tizenet6tadAsi filoz6fia 6tv6ltozott nehezen el6rejelezhet6 dont6sekkel mfjkod6 ritvonalv6lasztdssd (routing). A hdl6zati szintfi protokolltizenetek is megv6ltoztak annak hatAs6ra, hogy a tdvk6zl6si 6tvitelben az SS7ben megszokott MTP (Message Transfer Part) helyett megjelent az Ethernet 6s az lP. Az alkalmaz6si proto-
kollok fel6 ki kellett alakitani egy olyan adapt6ci6s 16tegszerkezetet, ami biztositja a kor6bban megszokott cimz6si m6dokat 6s lP felett is vesztes6gmentes tranzakci6s 6tvitelt nyrijt. Ezt az adaptdci6t a SigTran (Signaling Transport) protokollcsal6d l6trehoz6s6val 6rt6k el [1]. Ennek r6szek6nt az lP feletti vesztes6gmentes adat6tvitelt a TCP helyett a t6vkdzl6si inf rastrukt0ra k6vetelm6nyeihez igazod6 SCTP-t (Stream Control Transmission Protocol) [2] alkalmazzlk. Az MTP-funkci6kat illeszt6 SigTran adapt6ci6s protokollok kdzil az MTP-3 adapt6ci6s r6tege, az M3UA (Message Transfer Part 3 User Adaptation Layer) [3] terjedt el legink6bb. Az SS7 6s a SigTran protokoll-r6tegek jellemzd viszonyait jeleniti meg az 1. dbra. 1. dbra
Az S57 6s a SigTran protokoll-retegek iellemz6 viszonyai
:t*r '-----
i-:.--
i-'li
l'-l lr
I,, -
i 1l rurrp
s
tiL__
m l_,""'-_,r i ;r'
i
i
m
--]
M3UA
I
m ltPi l_l
Adatkapcsolati r. (Ethernet)
-:l
i
L_i
L--
r-i
:
I
ri.ikai
r6t"g
tev6kenys6ge szempontj6b6l passziv feladat, a moniloroz6 eszkdzdknek 0zenetveszt6s eset6n nincs lehetS-
s6grjk fjraaddst k6rni. A probl6mdra a vesztes6gmentes csomag-elkap6s jelenti a megolddst. ltt azonban nem elegendS elkapni, hanem egyedi id6pecs6ttel is el kell l6tni 6s val6s id6ben oszt6lyozni is kell az uzenetet. Ezut6n adhatjuk tov6bb m6lyebb elemz6sre 6s elt6rol6sra. Az AITIA 6ltal alkalmazott m6r6si architektf r6ban az ut6bbi feladatokat nagyteljesitm6nyf ipari PO-ken fut6 monitor-alkalmaz6sok l6tjdk el; a vesztes6gmentess6get, a pontos id6pecs6tel6st valamint a kovetelm6nyek szerinti sz6toszt6st pedig a C-board [4] nevfl, saj6t fejleszt6stli, FPGA-
lsuP _l
i_
A magasabb protokoll-szintek k6dol6s6ban is alapvet6 v6ltoz6st hoztak az fjabb protokollok. Korabban a t6mor, de rugalmasan b6vithet6 k6dol6si s6m6k (pl. ASN.1) orvendtek nagyobb n6pszer(s6gnek, mfg manaps6g a kisebb informdci6s0rris6gri, de emberi szemmel is konynyen olvashat6, ASCI|-alapri sz6veges k6dol6s terjed a maghdl6zati kommunik6ci6ban is. Az EPC a gyakorlatban a kor6bbiakhoz k6pest j6val nagyobb sebess6gf 6tvitelt haszndl: 10 Gbit/s 6s enn6l nagyobb sebess6gf Ethernetet. Ez rijabb probl6m6kat vet fel a teljes kor6 hAl6zatmonitoroz6s sor6n: a vesztes6gmentes csomag-elkapAs 6s a nanoszekundum nagysdgrendfi id6pecs6tel6s ezeken a sebess6geken c6lhardvert ig6nyel. Mivel a monitoroz6s a h6l6zat alap-
i
alapfi eszkoz biztositja. A 2. Abrdn bemutatott elosztott monitoroz6si architekt0reval az adatok el6feldolgoz6sa (id6pecs6tel6s, kovetelm6nyek szerinti csonkol6s, szfir6si krit6riumok szerinti sz6toszt6s) 6s a m6lyebb elemz6s (tranzakci6s folyamok rizeneteinek 6sszerendel6se, adatrekordok osszedllitdsa, statisztikek k6szit6se) is on-the-fly elv6gezhet6 [5]. Az rizenetek id5beli lefoly6s szerint tort6n6 k6zponti osszef6stllhet6s6g6t a C-board hardveresen t6mogatott, nanoszekundumos felbontAsri, n6h6ny tiz nanoszekundumos pontossagU id6pecs6tel6se biztositja. A monitorokon t6rolt informAci6 a kozponti, adminisztr6tori kliensekr5l el6rhetS 6s krllonf6le keres6si krit6riumok Monitoroz6 egys6g "A"
Monitorozo egys6g "B"
..lJ -9'9P'.,'. 10 Gbps .,,.
s€AroPEs
Monitorozo egys6g "C"
C-board
2. iibra l0Gbit/s htAl6zati szegmens e I o s ztott m o n ito roz es a a C-board segftsdg6vel
Monitoroz6 egyseg "2"
HTE lr.rroxou 2012
LXVI. EvroLvnv, zotz
37
HlRRoAsrucHrurrR
alapj6n kinyerhet6. Emellett a monitorok periodikus riportokat ktildenek az 6ltaluk gy6rtott statisztik6k16l. A felhaszn416i adatok 6s a jelz6sadatok ugyanazon a csatorn6n haladnak, 6s ezek sz6tv6laszt6s6hoz a protokollrizenetek legal6bb h6l6zati szintf (de gyakrabban tranzakci6s szintf) elemz6s6re van szUks6g. A forgalmi mint6k vAltozAsAI l6tva 6j ig6nyekket 6llnak etd az operdtorok is, akik eszkoz6ket keresnek a felhaszn6l6i adatfejl6cek intelligens feldotgozAs6ra. A fethaszndt6i adatok tranzakci6s folyamainak ossze6llit6s6hoz ezekb6l speci6lis adatrekordokat kell 6ssze6llitani (eXtended Data Record, XDR), ametyek ak6r az egyedi id6pecs6ttel ell6tott tizenetekre is t6rolnak mutat6kat. A forgalom mikroelemz6s6t ezen adatok alapj6n elv6gzd eszkozok az izleli intelligencia-alkalmaz6sokhoz 6s a
hdl6zat-optimaliz6l6si feladatokhoz is hasznos bemeneti adatokat nyfjtanak.
Ateljes htrl6zalra kiterjed6, passz[v monitoroz6st az oper6torok hibadetektiil6sra, a szolg6ltat6smin6s69 biz-
tositasara 6s er6forr6stervez6sre is haszn6lj6k. A monitoroz6si folyamat az adat-elkap6son 6s gyrlij-
t6sen (capture) tril m6g sz6mos funkci6t takar:
-
rizenetek pontos id6pecs6tel6se, sorba rendez6se; hfv6srekordok (Call Data Records, CDRs) 6s adatrekordok (Extended Data Records, XDRs)
-
ossze6llft6sa 6s visszakeres6se; kulcsfontoss69ri teljesitm6nyjetz6k (Key Performance lndicators, KPls) sz6mit6sa 6s
jelent6se;
-
lehet6s6g biztositasa komptex hiv6skovet6si
lek6rdez6sekhez; bitszintfi rizenetdek6dol6s protokollanalizishez stb. Mindezen funkci6k jelen vannak a gyakorlati hal6-
roz6sban, h isze n a h6l6zali kapcso lat-sz ntrli vizsgdlatok 6s a h6l6zati berendez6sek alkalmaz6sszintfi funkci6inak elemz6se mellett a felhaszn6l6i szint( analizis is fontos. zatmo
n
ito
i
3. Az LTE rendszeFelemei Az LTE h6lozal elemeit 6s a kozottrik definiiilt interf6szeket a 3. dbra szem16lteti.
s
3.1. A rddirfs hitlozat
Az LTE rddi6s hitl6zatdl az UMTS r6di6s hdt6zat6nak tov6bbfejleszt6sek6nt Evotved-UTRAN-nak (EUTRAN)
hfvj6k. Gyakorlatilag egyeilen funkcion6lis eleme van, az eNodeB (eNB). Az eddigi r6di6s h6t6zatvez6rtd etem, az RNC funkci6ja bekeruilt a maghAlozatba, igy az eNB be re ndez6sek kozvetle nri I a mag h 616 zalhoz csatlakoznak, a Mobility Management Entity-hez (MME). 3.2. Az Evolved Packet Core
Az LTE magh6l6zat (Evotved packet Core, EpC) t6nyeg6ben csak csomagkapcsolt-h6l6zati elemeket tartalmaz. A hagyomdnyos Aramkdrkapcsolt funkci6k lp alapon vannak kialakitva. Az 0j rendszerelemek a kovetkez6k [6]: 3.2.1. MME (Mobitity Management Entity)
Az MME a mobilit6svez6rl6s6rt felel6s, kulcsfontoss6g6 berendez6s az LTE hozzAl6r6si h6l6zat6ban. Tulajdonk6ppen mondhatjuk, hogy az EpC 6s az EUTRAN kozotti hat6rvonalon fekszik. A nev6b5l is ad6d6an szerepet j6tszik a handoverek vez6rl6s6ben, az fj eszkozok kivdlaszt6s6ban, az6rt hogy sikerrel z6rulhasson egy-egy handover ak6,r 2G, ak6r 3G vagy LTE hiit6zatr6l besz6ttjnk. A HSS-et (Home Subscriber Server) is az MME tartja a kapcsolatot, fgy szerepet jdtszik az el6fizet6 azonositds6ban, bejelentkeztet6s6ben 6s a roaming forgalom kezel6s6ben. Emellett az MME hozzal6tre, tartja fenn 6s t6rli mind az alap6rtelmezett, mind a dedik6lt viv6ket (Dedicated Bearers). 3.2.2. S-GW (Serving Gateway) Az S-GW a felhaszndt6i adatforgatom kiszotg6t6s66rt, ir6nyft6sa6rt fetet6s. Emeilett az eNB-k kdzotti 6s a 2G/3G-LTE kdzdtti handover eset6n is azt a stabil pontot testesiti meg, ami nem vAltozik a handover alatt. 3.2.3. PDN-GW (Packet Data Network Gateway) A PDN-GW biztositja a kapcsotatot ktjtsd adath6t6zatokhoz (pl. internet, c6ges priv6t h6lozat), kezeli a felhaszn616i v6gberendez6s kimen6 6s bejov6 adatforgal-
MME \
3. dbra
s 1rj
Az LTE htil6zat elemei 6s interfdszei i
s1-MilE I t
l
0*i,.*d[*, Serving GW
38
lrurOxOti,t 2O1Z
LXV|t. eVrOLyRM.2012
Az LTE maghdl6zat monitorozAs6nak kihivdsai m6t. Emellett olyan egy6b feladatokra is interf6szt biztos(t, mint p6ld6ul a QoS vez6rl6s vagy a szdml6z6ssal
kapcsolatos bedllit6sok.
okoz (,,network failure")' Ugyanez a ,,network failure"
hibaok jelezhet m6s probl6m6kat is. Aforgalmazdsi probl6m6t okozhatja a sikertelenril fe16pUlt GTP tunnel is,
amit a sikertelen GTPv2/Create Session Request okoz'
9.2.4. HSS (Home Subscriber Server) A HSS azLfE h6l6zatban a HLR/AUC (Home Location Register/Authentication Center) szerep6t veszi 6t' L6nyegOOen egy kozponti adatb6zis, ami a felhasznllok, illetve el6fizet6sek adatait t6rolja. F6 feladatai hozz6l6r6s kezel6ssel 6s bejelentkeztet6ssel kapcsolatosak'
A sikertelens6g ok6t a GTPv2/ Create Session Response r.izenet ,,cause" mez6j6nek 6rt6ke hordozza' Az egy6bk6nt sikeresen zajl6 csatlakoz6si folyamat kdzben az egyik 6rintett berendez6s vagy vezlrlS izeneteket tov6bbit6 link meghib6soddsa a m6r sikeresen befejez6dott r6szfolyamatokra is visszahat' A fel6ptllt kapcsolatok elbomlanak 6s a feljelentkez6s sikertelen lesz. Hasonl6an hivris-fel6pit6si hibdnak nevezhetjuk
4. A halt6zalta iellemzS
azt az esetet is, amikor a sikeresen csatlakozott k6sztil6khez rendelt alap6rtelmezett viv6 (default bearer) elbomlik. Ennek oka 6ltal6ban a felhaszn6l6i v6gberendez6sben keresend6.
hibalehet5s6gek vizsgilata Ebben a szakaszban az elSlizel6i el6gedetts6get 6rint5 hill6zali hibalehet6s6geket vizsg6ljuk - ide tartoznak a kulonf6le kapcsolati hibek, a mobilitdsmenedzsement hib6i, a v6laszid5k megn6veked6s6b6l ad6d6 hib6k 6s a forgalmaz6si probl6m6k is. Az LTE maghdl6zat6nak monitoroz6s 6val ezen hib6k okainak jelent6s r6sze f elterhat6. N6h6ny tipikus hiba ily m6don, a dial6gusokban megjelen6 param6terek figyel6s6vel kiszUrhet5 [7] a k6vetkez6kben ezek kdztll mutatjuk be a fontosabbakat'
-
4.1. LTE sztillftiisi protokollok hibiii
Az LTE hitl6zal 51-MME 6s S6a interf6sz6nek jelz6suzenetei SigTran-on tov6bbft6dnak, azaz az alkalmazott sz6llit6si protokoll az SCTP. A h6l6zati s6vsz6less6g csdkken6s6t, a torl6dAst, az SCTP asszocidci6k (ebben a protokollban igy nevezik a kapcsolatokat) meg-
szakad6s6t 6s egy6b, fennakad6sokat okoz6 probl6m6kat hasonl6an komplex vizsgAlatokkal lehet feltiirni, mint a TCP eset6ben. Ezekben seg(ts6get nyfjthat a [8] forr6s. Az S11 6s 55 interf6szen UDP sz6llitdsi protokoll tov6bbitja a GTPv2 (GPRS Tunneling Protocol version 2) veszte[9] jelz6sUzeneteket. Mivel az UDP nem biztosit k6r6s-v6tizenetek segmentes 6tvitelt, ez6fi az GTPv2 lasz darabsz6mdnak ellen6rz6s6vel lehet az tizenettovAbbit6st ellen6rizni. 4.2. A felhasznd16i v6gberendez6s kapcsolatlel6Pit6si Probl6mdi
A v6gberendez6s kapcsolatfel6pit6si hib6j6nak ne-
vezhetUnk minden olyan esetet, amikor a k6sztll6k nem tud felcsatlakozni a hill6zalhoz, vagy nem tud adatforgal mat bonyol itani a PDN-Gateway berendez6ssel' A csatlakoz6si sikertelens6get 6ltal6ban az S6a in-
terf6szen tdrt6n6 sikertelen Diameter/Update Location nincs re[10] jelzi, aminek oka lehet, hogy az elSlizelS unhibaok: (ilyenkor a ,,subscriber gisztrelva a HSS-ben nem hi6ny6ban megAllapod6s roaming known") vagy csatlakozhat a kiv6nt hAlozalhoz (,,roaming not allowed"). Ha az MME 6s a HSS kdzotti tizenet6tvitelben t0l nagy a k6sleltet6s (tipikusan roaming helyzetben), akkor a MME 6ltal ktildott k6r6s leid6zithet, miel6tt a HSS villasza meg6rkezne, igy ez is sikertelen feljelentkez6st
LITF lr,rsnrn^t
eo12
txvll FvfOfVnV. ZO
4.3. Dedicated Bearer (hozzdrendelt viv6) hibdk
A magasabb szolgAltat6smin6s6gi (QoS, Quality of Service) szintet ig6nyl6 szolg6ltat6sok ig6nybev6te16hez sztjks6ges Dedicated Bearer l6trehoz6sa sor6n el6fordu16 hib6kat c6lszer( a ktilonbozS szolgAltat6sokat biztosit6 QoS Class ldentifier (QCl) 6rt6kek alapj6n bontva vizsgAlni. lgy meg lehet hat6rozni, hogy esetleg QCI-
specifikus hib6r6l van sz6.
A Dedicated Bearer l6trehozds6t kezdem6nyez6 izenetet az S1-MME interf6szen tudiuk vizsg6lni, amelyen SI AP protokollt haszn6lnak. Mivel ezen a protokollon a kezdem6nyez6 uzenetre v6laszul minden esetben ,,successful outcome" Lizenet 6rkezik, ez6rl a val6di sikeress6g a hordozott param6terekb6l hatdrozhat6 meg. A Dedicated Bearer l6trehoz6s6nak sikertelens6g6t gyakran a r6di6s hozzAf6r6s hib6ja okozhatja, amelynek oka lehet egyszer(en a r6di6s kapcsolat megszakad6sa. El6fordul az is, hogy az eNodeB nem tudja biztositani a k6rt er6forr6sokat, mert nem 6ll rendelkez6sre a k6rt bitsebess6get biztosfl6 frekvencias6v vagy nincs megfelel6 id6r6s, esetleg nincs elegend6 feldolgoz6si kapacitas vagy mem6ria hi6ny l6p fel az alulter-
vezett forgalom miatt. 4.4. Viilaszid6
Hasznos mutat6k lehetnek az egyes m(veletek soran
v6gzett iddm6r6sek, melyekkel az egyes berendez6sek v6laszidej6t vizsg6ljuk. Ezekb6l a minimum, maximum 6s 6tlag6rt6kek vizsg6lat6val a kU16nboz6 eszkozdk terhelts6g6t lehet kimutatni. 4.5. A lelhaszniil6i v6gberendez6s kapcsolat-megszakaddsi ptobl6mdi
A v6gberendez6s kapcsolat6nak megszakadAs6r6l akkor besz6lhettink, amikor a r6di6s kapcsolat megszakad a felhasznAl6 k6sztil6ke 6s a h6l6zat kozdtt. llyen
esetekben az eNodeB ktild az MME-nek egy SlAP/UEContextReleaseRequest tizenetet, melyben az okot jelz6 mez5l,,Radio Connection With UE Lost" 6rt6kfire 6llitja. llyenkor a k6sztjl6k 6s az eNodeB kozotti kapcsolat nyugalmi dllapotba kertll, de az eNodeB 6s a SGW/ PGW fel6 az adalhllozati kapcsolat aktiv maradhat.
39
HinRoAsrEcHrurrR
Az ilyen megszakad6st a felhaszn6l6 nem mindig veszi 6szre, mert a forgalmaz6si profil miatt nem folyamatos a letdlt6s (bdng6sz6s, email letolt6s). Amennyiben e169 gyorsan 0jra6ptil a kapcsolat, akkor lehet, hogy csak egy pillanatnyi kimarad6st 6rz6kel vagy a szok6sosn6l nagyobb v6laszid6t, eseileg tassabb letdtt6st. Azonban val6sidejfi szolg6ltat6s ig6nybev6tele eset6n
a jelens6g azonnal 6szrevehetd, igy c6lszerri a kapcsolat megszakad6sokat QCI alapj6n is sz6molni, igy jobban k6vethet6, hogy a felhaszn6t6i 6lm6nyt mennyire befoly6soljdk ezek az esem6nyek. 4.6. Diameter Watchdog lunkcid A HSS 6s az EIR (Equipment tdentity Register) kap-
csolatokban haszniilt Diameter protokollban van lehet6s6g az 6tviteli rit hib6j6nak detektatasera. Ebben az esetben c6lszerfi min6l hamarabb felismerni a hib6t, hogy minimalizllhat6 legyen a nem el6rhet6 agent-ek szlmAra tort6n6 tizenetkUld6s, ami k6sleltet6st okozhal az rizenetv6ltasokban, valamint, hogy min6l hamarabb helyre lehessen 6llitani a hib6t. Ennek felismer6s6re a Device-Watchdog-Request 6s Device-WatchdogResponse tizenetp6r haszn6lhat6. 4.7. Handover probl6miik
A handover sor5,n az el1'fizelS az egyik cella terrilet6r6l egy m6sik cella tertilet6re megy dt, amely ak6r egy mrisik tipusri r6di6s hllozat r6sze, azaz tipikusan ugyanannak a szolgAltat6nak a GPRS vagy UMTS r6di6s hozzAl6r6si-h6l6zata. Ennek fdzisai 6s azok sor6n esetlegesen fell6p6 hib6k a k6vetkez5k. 4.7. 1 . Handover el6k6szftds A c6l cella elSk6sziti 6s lefogtatja a kapcsotat 6tv6tel6hez sztjks6ges r6di6s erdforr6sokat, 6s elkrildi az 0j riidi6s param6tereket a 169i cell6nak. Lehets6ges hib6k: - nincs el6g er6forr6sa a c6l ceil6nak, - jelz6s6tviteli probl6ma a k6t ceila kcjzott, - protokoll hiba valamelyik 6rintett berendez6sben, - param6terez6si hiba a htlozatban (pl. lP 0tvonalv6laszt6s).
4.7.2. Handover v6grehajtds A handover v6grehajtSsa sor6n az 6j cella elkrildi a Handover Command-ot a k6szril6knek, a k6szril6k sikeresen meg6rkezik az rij cetl6ba. A tipikus hibdk a k6vetkez6k:
-
a k6sztil6k ,,reconfiguration failure" Lizenettel visszautasitja a handovert, a folyamat kozben a r6di6s kapcsolat megszakad a k6sztil6k 6s a cella kozdtt.
Att6l ftlgg6en, hogy a k6szril6k hov6 szeretne 6tmenni, krilonboz6 handoverekr6l besz6lhettlnk - X2 handover: X2 interf6szen kdzvetlentil osszekotcitt eNodeB-k kozdtti handover, - S1 handover: kdzvetlentil nem 6sszekot6tt eNodeB-k kdzdlt, - lnterRAT handover: m6s tipusri hillozal (2G vagy 3G) ir6ny6ba vagy ir6ny6b6t tort6n6 handover.
L6
A X2 6s S1 handover ktizdtti megkrilonb6ztet6st az interf6sz alapj6n lehet megtenni. Az LTE hAl6zatba 6rkezni vagy onnan t6vozni szlnd6koz6 k6sztjl6k handoverj6t az 51 interflszen az SlAP/Handover Required tizenet Handover Type param6te16b6l lehet meg6llapitani.
4.7.3. Adattovdbbitds kozbeni handover Ez az esem6ny azX2 handover eset6ben fordulel6, amikor a k6t eNodeB kozvetlen kapcsolatban van egym6ssal. A sikeres handover sor6n az SGW, valamint az
[j
eNodeB is inform6ci6t cser6l a r6gi eNodeB-vel. Az adattov6bbitAssal kapcsolatban hasznos lehet a kdvetkez6 dolgokat vizsg6tni:
- tov6bbitott r.lzenetcsomagok sz6ma, - elveszett csomagok sz6ma, - az X2APlHandoverRequestAck 6s az X2-n krlldott -
els6 felhaszn6l6i csomag kozdtti id6, a 169i S1-U interfeszen 6rkez6 els6 ,,end marker,'6s az X2-n ktildott els6 user plane csomag k6z6tti id6.
5. Lehets6ges KPl.k Az EPC kril6nf6le interf6szein kinyerhet6 kulcsfontos-
s6gI indikdtorok gyrijt6si hety6t (LTE interf6sz) 6s
a
vizsgiiland6 rjzenettipusok 6s -param6terek protokolljail az 1. tdbl1zat fogtatja ossze. A Kpl-k sz6mft6s6nak alapelv6t a kovetkez6kben t6rgyaljuk - ezek egy r6sze 3GPP aj6nl6s r6szek6nt is megtatAthat6 [11]. Ezek sz6mit6sa gyakran 0zenetsz6mok ar6ny6ra vezethetd vissza: egyfajta dial6gus-kezd6 (Request) 6s pozitiv vagy negativ vdlasz (Response, Answer vagy Reject) Uzenetek ar6ny6ra. Terjedelmi korl6tok miatt nem adjuk meg az dsszes KPI sz6rmaztat6s6t z6rt matematikai alakban: az Attach sikeress6gi arlnyhoz megadott osszeftjgg6sek 6rtelemszerri tizenettipusokkal t6rt6n6 behelyettesft6s6vel a tov6bbiak is sz6rmaztathat6k. 5.1. KPI-szdrmaztatiisi pritda: a csatlakozdsi sikeressdg (Attach)
Acsatlakoz6si sikeress6g egy igen fontos m6r6sz6m, hiszen ha egy felhaszn6l6 nem tud csatlakozni, akkor egydltal6n nem 6ri et a h6l6zati szotg6ttatdsokat. A h6l6zat el6rhet6s6g6t mutat6 m6rdsz6m meg6llapit6s6hoz a sikeres csatlakozasokat (Attach Accept rizenetek menynyis6ge) vetjrik ossze az dsszes csatlakoz6si kis6rletekkel (Attach Request lizenet darabszdma). Azokat az
Attach Request tizeneteket vesszrlk figyelembe, amelyekben az ,,Attach type" param6ter 6rt6ke ,,EpSAttach". A sikeres csatlakoz6sok ariinya:
AttachsuccRate(%) =
J
1=:n]**9!t
-., oo
A sikertelen csatlakozasok eset6ben c6lszer6 a visz-
szautasites okai szerint sz6molni az arilnyokat. Sikertelen csatlakoz6sok ar5,ny a:
AttachRejRate(%) =
)nttacn
Reject
reject cause
)Attach
Request
* 100
Az LTE maghdlozat monitoroz6s6nak kihivdsai
6. Osszefoglalis
5.2. Felhaszndkii adatmennyis6g 6s sdvsz6less6g m6r6se
A felhaszn6l6k 6ltal forgalmazott adatok mennyis6g6t tobbf6lek6ppen 6s a hdl6zat tdbb pontj6n is m6rhetjrik. A r6di6s interf6sz mutatja a legink6bb az elSlizelS dltal 6rz6kelt sebess6get, de ennek m6r6se neh6zkes. Az SGi interf6szen viszont mAr neh6z az egyes adatfolyamokat a felhasznAl6khoz rendelni, mert nem jelennek meg a felhaszn6l6t konnyebben azonosft6 jellemz6k (pl. a tunnel-azonosit6k), csak az lP-cfmek. Emiatt a felhaszn6l6i adatmennyis6get az s1 vagy s5 interf6szen ctllszer[i m6rni. A h6l6zaton beltil a GTPvI felhaszn6l6i csomagokban sz6llitott adatmennyis6get a kapcsolathoz 6s a felhaszndl6hoz rendelt lP cimek 6s TEID (Tunnel Endpoint ldentifier) alapj6n lehet m6rni 6s a felhaszn616khoz rendelni. C6lszer6n az uplink 6s downlink ir6ny0 forgalmat m6rni, valamint a sz6llitott protokollokat (az UDP 6s TCP portok alapj6n) megkrjlonboztetni. Figyelembe kell venni azonban, hogy VPN (Virtual Private Network) kapcsolatok eset6n az lP csomagokban az lP fejl6cn6l m6lyebben l6v6 adatok titkosftottak.
A m6rt adatmennyis6get 6tlagolhatjuk p6ld6ul id6-
A korszer( mobiltelefon h616zatok berendez6s-funkci6inak (pl. az LTE magh6l6zati MME, SGW, PCRF) 6s adat6tviteli techno169i6j6nak (SigTran, GTPv2, Diameter) v6ltoz6sa, valamint a novekv6 kapcsolati sebess6gek (10 Gbit/s Ethernet) miatt ahAlozali szolg6ltat6sok uzemel-
tet6i folyamatosan 0j kihiv6sokkal szembestilnek. A s ikeres uzemeltet6si mutat6k el6r6s6hez a hal6zati elemek 6s kapcsolataik 6llapot6t folyamatosan figyelni kell. Ennek a folyamatos figyel6snek az egyik kulcsfontoss6gri eleme a h6l6zatmonitorozds '5s az ezen alapu16 h6l6zatiforgalom-analfzis, amelyre manaps6g m6r a felhaszn616i adatfolyamok szintj6n is ig6ny mutatkozik. A monitoroz6s sor6n a vesztes6gmentes csomagelkapds 6s az uzenetek nagy pontoss6gf, egyedi id6pecs6tel6se kulcsfontoss6gf feladat. Ezen kdvetelm6nyek teljesit6se alapozza meg a hat6kony protokoll-analizist, ami a hib6k feltiir6sanak fontos eszkoze. A hibaokok sikeres felt6rds6hoz ismerni kell az ezeket indik616 tizenetparam6tereket. Ezen tud6s birtok6ban hat6kony KPI-k defini6lhat6k, melyek gyfjt6s6vel 6s figyel6s6vel kritikus hib6k automatikus jelz6se is megoldhat6.
szakra, ha valamilyen id6szakra vonatkoz6 6tlagos adatdtviteli 6rt6ket szeretn6nk. Ha az adatmennyis6get md-
lrodalom
sodperces intervallumokra dtlagoljuk, akkor megkaphatjuk az adott kapcsolat 6tlagos s6vsz6less6g profilj6t. Az Atlagol6st v6gezhetjtjk kapcsolatonk6nt is. Az 6tlagoldssal azonban a val6s forgalmi profilban
tapasztalhat6 pozitiv 6s negativ cs0csokat elsimitjuk, lgy azidSszakos t0lterhel6seket vagy hiba miatti kies6seket ezen mutat6k segits6g6vel csak korldtozottan 6r-
[1] L. Ong, l. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, l. Juhasz, M. Holdrege, C. Sharp, .RFC 2719: Framework Architecture for Signaling Transport," IETF, 1999. [2] R. Stewart ed., "RFC 4960: Stream Control Transmission Protocol,"
z6kelhetjtik. I
tETF, 2007.
. tdbl6zat Az LTE interfdszeken gy(ijthet6 fontosabb KPI-k
WI
LTE inteqfdsz
Protokall
s1
SigTran I SLAP
s1
SigTran I SIAP
,,Service Request" sikeressd gi ardny
sl
SigTran I SIAP
A csatlakozdsok eldobdsi aritnya
s1
SigTran
,,Create sessiotl" sikeressd gi ar(tny
sll s5 6s sll s5 6s sll
GTP-C GTP-C
s56ssll
GTP-C
s5dssll
GTP.C
s6a
SigTranl DIAMETER
s6a
SigTranl DIAMETER
Jellemzd
,,Attach" sikeressd gi ardny A dedikdh hordoz6 dtlagos
,,C reate
6s max.
fel/pitlsi ideje
s5 6s
Bearer" sikeressi gi ardny
,,Modifi Bearer" sikeressd gi aritny ,,
D elete Session" sikeressd gi
ardny
,,Downlink Data Notification" sikeressd gi ardny ,,
Update Loc ati orz" sikeressd gi ardny
,,
Aut
he nt
ic
at i o n I nfor mat
io
Felhaszndl6i adaforgalom
n"
s
ike r e s s 6 g
i
ar (t ny
- XDR-ek 6s statisztik(tik
HTE lr.rroxoM 2012 - LXVI. EvrolYnu, zotz
s1
ls
s5
I SIAP
GTP-C
GTP-U
41
HlRRoAsrecHrurxR
[3] K. Morneault, ed., J. Pastor-Balbas, ed., "RFC 4666: Signaling System 7 Message Transfer Part 3 (MTP3) - UserAdaptation Layer (M3UA),,
A szerz6kr6l VIRCI pAL a Budapesti Mfszaki 6s Gazdasagtudomanyi Egyetem docense, a Tdvkozl6si 6s M6diainformatikai Tansz6k munkat6rsa. Villamosm6rnoki oklevel6t 1997ben, PhD-fokozatdt 201 1 -ben szerezte. 1 999-ig az Ericsson Magyarorszdg szoftverfejleszt6je, 2002-ig a Tecnomen lrorszdg rendszertervez6.le, az intelligens h6l6zati perif6ridkat tervez6 csapat vezet6je volt. F6bb kutat6si teruletei a h616za! 6s szolg6ltat6s-menedzsment, a hdl6zati kapacit6svizsgelatok, a hibaok-analizis, valamint a v6gpontok kozotti (end-to-end) min6s6gbiztositesi 6s szolgaltatas-szint biztositasi m6dszerek.
tETF, 2006.
[4] P. Varga, l. Moldovdn, D. HorvAth, S. pt6sz, "A Low Power, Programmable Networking platform and Development Environment," Advances of Network- Embedded Management and Applications, pp.1 9-36, Springer, 2010. [5] P. Varga, L. Gulyas, "Traffic Analysis Methods to Support Decisions at the Knowledge Plane," lnfocommunications Journal, LXV I 4, pp.50-56, 20 1 0. [6] M. Olsson, S. Sultana, S. Rommer, "SAE and the Evolved Packet Core: Driving The Mobile Broadband Revolution " Academic Press, 2009. [7] R. Kreher, K. Gaenger, " LTE Signaling: Troubleshooting and Optimization," Wiley, 2010. t8l R.R. Stewart, Q. Xie, "Stream Control Transmission Protocol (SCTp): A Reference Guide," Addison-Wesley, 2001. [9] "TS 29.274: Evolved General Packet Radio Service (GPRS); Tunnelling Protocol for Control plane
SZELINDI CABOR tgsa-Oan szerzett viilamosm6rnoki diplom6t a Kand6 K6lmdn Mrjszaki F6iskot6n tevkdzt6si szaki16nyon, majd 2002-ben a Budapesti Mriszaki Egyetemen okleveles vrllamosm6rnoki diplomat, m6r6s- 6s
o
r{r \#'r
rendszertervez6si szakir6nyon_ 1 999 6s 2002 kozott a Hir-
kozl6si F6felugyeleten a tavkozl6si szolgaltat6k hat6sagi ellendrz6s6nek egys6gesit6s6ben vett 16szt, majd vezet6kes tavkoz16si h616zat min6s6gmonitoroz6 rendszer adminisztreci6let v6gezte. 2002 6ta az AITIA lnternational ZtL tevkdzl'si Sgazatdnak vezet6 term6ktemogat6 m6rnokek6nt t6vkozl6si monitoroz6 rendszerek, teszt berendez6sek, valamint aktiv eszkozok tesztel6s6vel, integ1615s6val, hibakeres6s6vel foglalkozik.
Sgy CABOR a Szegedi Tudomenyegyetemen szerzett matematikusi, illetve programterve26 matematikusi diplomat; mindkettSt 2003-ban. 2005 6ta az AITIA lnternational ZRt. szoftverfejleszt6 m6rn6ke. SzakterUlete a ZGlSGl LTE h6l62atok telekommunik6ci6s protokoiljai, jelz6sfolyamatai, mobilitas-menedzsmentje, valamint az 6ramkorkapcsolt 6s csomagkapcsolt maghdl6zat komplex forgalmi vizsgalata.
(GTPv2-C); Stage 3,"
3GPq 2008.
[10]
.IS
29.272: Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol,"
3GPP, 2008. [11] "TS 32.455: Key Performance lndicators (Kpt)
for the Evolved Packet Core (EPC); Definitions," 3GPP,2010.
a Budapesti Mfszaki F6iskola Viilamosm6rnoki Kardn hiradSstechnikai szakirdnyon v6gzett 2008-ban. 2008-201o-ig a Magyar Tetekom Nyrt.-n6t el6szdr mint 6tviteltechnikai m6rn6k, k6s6bb a core-hal62at fejleszt6si osztdlyon jelz6shdl6zati monitoring t6makorben tev6kenykedett. 201 O-t6l pedig az AITIA lnternational Zrt-n6l foglalkozik a passziv (monito1026) 6s aktiv telekommunikaci6s rendszerekkel, mint term6ktamogat6 6s tesztm6rnok. CSESZKO ENDRE
