Protokolltechnológia (BMEVITMA364) nemhivatalos minimáljegyzet v T A R T A L O M

Átírás

1 Protokolltechnológia (BMEVITMA364) nemhivatalos minimáljegyzet v T A R T A L O M BEVEZETŐ HANGÁTVITEL HANGDIGITALIZÁLÁS (PCM) PCM KERETEZÉS PCM SZABVÁNYOK ANALÓG ELŐFIZETŐI HÁLÓZAT JELZÉSEI TÁRCSÁZÁS SZÁMOZÁS JELZÉSEK OSZTÁLYOZÁSA JELZÉS ÉS BESZÉDCSATORNA KAPCSOLATA (Könyv 7. fejezet) MILYEN JELZÉSRENDSZEREK ÉS PROTOKOLLOK VANNAK ÉS MELYIK MIRE VALÓ? DSS1 (Könyv 6. fejezet) SS7 JELZÉSRENDSZER ÜZENETTOVÁBBÍTÁS (Könyv 8. fejezet) MTP DATA LINK / LINK LEVEL HIBAJAVÍTÁS MTP 2 ALATT SIGNALLING NETWORK LEVEL JELZÉSHÁLÓZAT MENEDZSELÉS NEMZETKÖZI HÍVÁSFELÉPÍTÉS ISDN USER PART ISUP JELZÉSEK JELZÉSKAPCSOLAT VEZÉRLŐ EGYSÉG (SCCP) TRANZAKCIÓS KÉPESSÉGEK FELHASZNÁLÓI EGYSÉG PROTOKOLLTECHNOLÓGIA ELMÉLET (Könyv 2 3. fejezet) ADATSPECIFIKÁCIÓ SDL INRES (Könyv 3. fejezet) SDL INRES ASN.1 Abstract Syntax Notification One Kódolási szabályok TAG Hosszkódolás 1

2 Hogyan kell egy elég összetett üzenetet kódolni? TESZTELÉS (Könyv 5. fejezet) Teszttípusok Szabványos tesztelrendezések Test Case készítés A TTCN NYELV (Könyv 5.2. fejezet + Ericssonos diák) HelloWorld Adattípusok Strukturált típusok Megkötések Konstansok, változók, paraméterek Modulparaméterek Operátorok és programvezérlés Timerek Tesztkonfiguráció Komponensek Függvények Ítéletek (verdict) Konfigurációs műveletek Adat templatek Kommunikáció Viselkedés leírása A GSM HÁLÓZATI ARCITEKTÚRA (Könyv 12.) Elemek és magyarázatuk Használt protokollok PLMN en belülre: Mobilhálózatoban használt azonosítók: A díjszabásokról Titkosítás és Authentikáció Lokalizálás Hívások Handover Short Message Service Jelzéskapcsolat bontása CSOMAGKAPCSOLT ÁTVITEL GPRS képes eszközök Pagingcsökkentés GPRS hálózat elérése GPRS kapcsolatok felépítése SZÁMHORDOZÁS Megvalósítások Mobilhálózatokban Színes hívások ZH feladatok LAPD javítási módszer MTP2 javítási módszer LAPD TEI menedzselési eljárás Összetett TCAP tranzakció (részletesen, azonosítókkal, üzenet és komponenstípusok) 2

3 Nemzetközi hívás felépítése (nemzeti és nemzetközi jelzéspontok, kódok hozzárendelése, felépült jelzéskapcsolatok, OPC, DPC értékek) SCCP globális címfordítási képessége Nyílt számozási rendszer összehasonlítása a zárt számozási rendszerrel ASN.1 leírás & TCAP típusok EU/US PCM struktúra ismertetése Minta jelzéshálózat átkonfigurálódása adott meghibásodások esetén Két különböző központban lévő ISDN készülék közti hívásfelépítés Teszttípusok bemutatása Protokolltesztelés leírása, milyen dokumentációk szükségesek? TCAP összetett tranzakcióra mutasson egy példát. Hogy tudunk hibát javítani? Teszttípusok SCCP mikor és hogyan javít, egy példán keresztül Vizsgafeladatok Tesztkomponensek felrajzolása, tesztesemény kimenetele, folyamata TTCNv3 kód alapján ASN.1 leírásban bemutatott MAP üzenet kódolása, küldhető TCAP típusok GSM location update NSS ben Mikor kell a GPRS esetén a paginget csökkenteni SMS útja a feladótól(a) a központig(b) GSM legfontosabb azonosítói Mobil állomás autentikálása, miért van rá szükség és mikor, hogyan történik? Paging csökkentési lehetőségek BEVEZETŐ A jegyzet az előadások, gyakorlatok anyagából készült a Könyv Adamis Gusztáv Kommunikációs Protokollok [55069], Műegyetemi Kiadó 2004 felhasználásval. A jegyzet nem helyettesíti az előadások, gyakorlatok látogatását, anyaga nem egyezik a garantáltan elégséges követelményekkel, célja az emlékeztetés, vizsga előtti ismétlés könnyítése. Vagyis talán az a jó módszer, hogy a tartalomjegyzéket tételsornak használva véletlenszerűen felmondunk fejezeteket és ha egyezik a felmondott a leírttal, akkor továbblépünk. Igyekeztünk odafigyelni írás közben, de sajnos nem garantálható, hogy teljesen tartalmi és helyesírási hibáktól mentes a jegyzet. Jó tanulást ;) Szerkeszthető verzióért érdeklődj az asztrikb@gmail.com címen! HANGÁTVITEL A khz közti sáv a jól felismerhető beszéd erre kell optimalizálni. Az átvitel áramköralapú, ami mindig érpár, figyelembe kell venni a csillapítást / torzítást és a hozzáadott 3

4 zajt. Az áramkör hibrid ha szétválasztja a két beszédirányt így lehetséges eltérő módon erősíteni irányonként, viszont ez csillapítással jár és torzítással, ha nem 100% tökéletes a szétválasztás ( echo) Core network két telefonközpont közötti (2 érpár = 4 huzal), irányonként független átvitel. Sávszélessége ~36 MHz (coax).. ~10 GHz (opt) Echotörlés 1 nagy impedanciával lehetséges, adóoldalon modellezi a jelutat a vett jelből így ismerve az adott jelet, a késleltetést és a kábelkarakterisztikát ki tudja szűrni mi volt az echo. Multiplexálás 1 kábelen [=közegen] több jel továbbítása. A jeleket szét kell választani (idő / frekvencia / kód szerint) és el kell választani (interchannel influence (nem ideális, sávon túllógó jelek) gap (védősáv)) Időosztás (TDM) szemléltető megvalósítás: forgókapcsoló, ami a mintavételezési frekvencia kétszeresének megfelelő sebességel fordul körbe, így minden adó sorra kerül a periódusidő alatt. Vevőoldalon ugyanilyen kapcsoló forog körbe, minden időszeletben más adás vehető. Problémás, hogy nem szinkron a két forgókapcsoló, valamint az, hogy az analóg jel (mivel nem egy forrásból származik, hanem több teljesen függetlenből) nagy ugrásokat is tartalmaz. Multiplexálás távolságbeli korlátai Ping pong TDM esetén max 1.5 km a 125 μs miatt, FDM esetén ugyanez 8 10 km. HANGDIGITALIZÁLÁS (PCM) A digitális jel [egyik] legnagyobb előnye az, hogy míg az analóg jelnél a zaj együtt erősödik a jellel, digitális jelnél ez a mintavételi határokkal kiszűrhető. A digitalizálásnak négy lépése van: Mintavétel 125 μs onként vesz egy mintát az analóg jelből. Kvantálás diszkretizálja az analóg jelet; adott intervallumba eső mintára mindig ugyanaz a jel megy ki. A konkrét jel pedig az intervallum közepén mért érték. Itt információveszteség is történik, ami a mintavételezési frekvencia növelésével tompítható. A kvantálás tulajdonsága, hogy a bemenő (analóg) és a kimenő (digitális) jel különbsége adott legyen ez a döntési intervallummal megszabható. 4

5 Logaritmikus kvantálás lényege, hogy az emberi fül arányokat érzékel, az érzékelési karakterisztikája majdnem logaritmikus. A döntési szintek nem lineárisan követik egymást, hanem egy adott torzító függvény (ami logaritmikus és a tranzisztor karakterisztikájára hasonlít) szerint. Ez a függvény az USA ban a μ law az EU ban az A law szerint specifikált. A döntési szint környékén kis amplitúdóval váltakozó jel (mid riser) értelemszerűen végig 0 kimeneti értéket kell adjon, ez hiszterézissel oldható meg (első intervallum közepe a 0) Kódolás a bemeneti értékek előre definiáltak (+/ 8 értékre, melyek μ vagy A law szerint számítottak) ezek alkotnak az egyenlő lépésközű mérés után szegmenseket. A szegmenseket 16 lineáris intervallumra osztjuk. Szóval a függőleges tengelyt, amin a jelszintek vannak először felosztjuk 4+4 részre nemlineárisan, majd minden egyes részt továbbosztunk 16 felé lineárisan. Egy ilyen szegmens megfelel egy bitnek, 8 bit pedig megfelel egy kódszónak: * előjel szegmens kijelölés intervallum kijelölés Vonali kódolás lehetséges jelátmenettel (Non Return to Zero önszinkronizáló és DC komponens nélküli, viszont sűrűbb mintavételt igényel), jelszint alapján (több szinten kódol több bit / időegység 2Bits1Quad), előre definiált hullámmintákkal (csak a hullámminta sorszámát kell küldeni GSM Full / Half Rate) PCM KERETEZÉS ISDN PRA szerinti 30 B (beszéd) + 2 D (signalling / control) csatornás Modulation egy frame je pontosan 125 μs ig tart és így néz ki: Pulse Code 5

6 D B D B = 125 μs Az első D mindig az előre definiált SYN kódszó [X ], a 16. időrés (2. D) pedig a signalling mikor melyik időrésben kezdődik / fejeződik be beszélgetés. 5 biten azonosítja az időrést, 2 biten pedig a státuszt (kezdődik, befejeződik, nem változik). Multi frame az, amikor 16 frame áll össze, 2 ms ig tart. A multi frame n belüli frame k egyes 0. időrései felváltva tartalmaznak SYN kódszót és SERV jelölést, a 16. időrések pedig megoszlanak a 31 multiframe keret között minden csatornára jut 2 x 4 bit a párosítások így 1 17, 2 18,, i, 16+i, 15, 31. *A *B SYN B 1&17 B SRV B SYN B 3& Ha a 17. beszélgetés az *A pontban ér véget, akkor az még ebben a multi frame ben érvényre jut. Ha a *B pontban ér véget, akkor már meg kell várni a következő multi frame t. PCM SZABVÁNYOK EU Unrestricted CRC képes kód: 8 keret 4 bit CRC vonalminőség jobb. Sub multiframe: 8 keret; ami az alapvető védelmi egység is. Sebesség Mbps = 32*64 kbps. US - Restricted 24 csatorna / frame, csak beszéd. Signalling az egyes beszédcsatornák utolsó bitjein kap helyet, a 6. és 12. frame kben. Multi frame nként 12 frame fér el ( 1.5 ms). Multi frame esetén a SYN kódszó keretenként a legelső bitekben van. Overhead kicsi. Sebesség Mbps = 24*56 kbps. ANALÓG ELŐFIZETŐI HÁLÓZAT JELZÉSEI Polling alapú előfizető infó detektálás: off hook esetén zár az áramkör és indul a folyamat: 6

7 TÁRCSÁZÁS A központban lévő számjegytároló regiszterből igényel az előfizetői hurok egy helyet. A számjegytovábbításra több módszer van: Pulse annyiszor szakad meg mechanikusan a hurok ahányas szám kell. 66 ms nyi szakadás, köztük egyenként 33 ms szünettel jelent egy számjegyet. Dual Tone MultiFrequency hangjelet állít elő különböző szinuszjelből 1 1 et kiválaztva és azokat összegezve. sin() 1209 Hz 1336 Hz 1477 Hz 1633 Hz 697 Hz A 770 Hz B 852 Hz C 941 Hz * 0 # D Hz Hz = 2106 Hz 7

8 SZÁMOZÁS Nyílt számozási rendszer körzeten belüli számokhoz nem kell előtét. Nem lehet előre tudni a számok hosszát, ezért prefix, (0 val, vagy 1 gyel nem kezdődhet szám), timer méri, hogy vége e a tárcsázásnak. Zárt számozási rendszer előre lehet tudni a szám hosszát, minden számjegyet be kel ütni. 0 és 1 is használható. Szám összetétele (belfödi előtét + szolgáltatás / hálózatkijelölő) = belföldi rendeltetésű szám. A központ feladata lefordítani a telefonszámokat, kezelni a számhordozást. JELZÉSEK OSZTÁLYOZÁSA Analóg / Digitális Vonali (hurok szakad, zár, PCM 16. időrés) / Regiszteres (hívószám jelzések) Forward ( ) / Backward ( ) Előfizetői / Központi (interswitch) Sávon belüli (in band: DC komponenses, DTMF) / Sávon kívüli (off band: felépítés/bontás) Csatornához társított (kell beszédcsatorna) / Csatornafüggetlen (fizikailag is; DSS1 & SS7) JELZÉS- ÉS BESZÉDCSATORNA KAPCSOLATA (Könyv 7. fejezet) A jelzésátvitelnél kötelező a sorrendiség és a hibamentesség biztosítása, nem kötött a csatornához, csak az átvitel típusához (pl.: SS7). A beszédátvitelnél csak a 125 μs alatti késleltetés a fontos (pl.: DSS1). A független jelzéshálózat előnye, hogy komplikált, digitális üzenetek egy csatornán akár többféle szolgáltatást is megvalósíthatnak, hátrány, hogy drága kiépíteni és nem ellenőrizhető a beszédcsatorna folytonossága. Közös csatornás hálózat minden beszédközponthoz (a circuit / beszéd / trönk szinten) tartozik Signalling Point (a link / signalling szinten), ami a jelzéshálózat része külön 8

9 funkcionalitással. A Signalling Transfer Point olyan jelzéspont, amihez nem tartozik központ, csak jelzéseket továbbít a jelzéshálózaton belül ( signalling links). Alapvető, hogy a beszédhálózat két végpontja (akik beszélnek) megegyezik a jelzéshálózat két végpontjával, csak az útvonal különbözhet. Jelzéshálózati mintahálózat quasi associated network nemzetközi szabvány, hogy minden pontban legalább két lehetséges átviteli útvonal legyen (megbízhatóság, redundancia). Azért csak quasi mert a kapcsolódáskor választott útvonal a beszélgetés során nem változik, mert a helyes sorrend a jelzések között csak így garantálható (de a forward / backward jelzések mehetnek már más más útvonalon). A vízszintes / ferde folytonos összeköttetések (Pr1) (2 párhuzamos útvonal van a végpontok között!) 50 50% ban osztoznak a terhelésen. A függőleges / szaggatott összeköttetések (Pr2) normál esetben 0% ra terheltek. MILYEN JELZÉSRENDSZEREK ÉS PROTOKOLLOK VANNAK ÉS MELYIK MIRE VALÓ? A következő részekben sok rövidítés fog szerepelni, ami protokollokat és jelzésrendszereket takar. Segítségként itt foglaljuk össze melyikkel hol lehet találkozni és mi a feladata. Réteg / funkció Terminál Központ Központ Központ Központ Központ Alkalmazás (PCM) TCAP ( ASN.1) ISUP Híváskezelés DSS1 TCAP ( ASN.1) ISUP Átvitel / keretek LAPD SCCP SCCP / ISUP Hálózat ISDN D MTP 3 MTP 3 Adat ISDN D MTP 2 MTP 2 Fizikai ISDN D MTP 1 MTP 1 9

10 DSS1 (Könyv 6. fejezet) A Digital Subscriber Signalling System No. 1 az ISDN terminálok és ISDN hálózat közti jelzésekre szolgál. Három rétege van: fizikai (ISDN D csatorna), Link Access Procedure on D channel (a konkrét keretek) és a DSS1 (híásfelépítés & bontás) LAPD fix keretformátum, nyitó/záró flaggel, 4 mezővel. Alapszabály: 5 db 1 es után kötelező 0 t beszúrni, különben tévesen véget érhet a keret octet + + CÍM 2. & 3. octet + + VEZÉRLÉS 4. (+5.) octet a 4. mintája adja meg a vezérlés hosszát + + Info / 5. or 6... X. octet + + FrameCheckSeq N 2. octet (sum) N 1. octet N. (last) octet + + LAPD címmező Két octetből áll: Service Access Point ID (6 bit) Command response (parancs v. válasz 1 bit) fix 0 A SAPI kijelöli melyik 3. rétegbeli ponton milyen információ megy tovább Terminal Endpoint Identifier (7 bit) fix 1 A TEI funkcionális egységenként egyedi azonosító fix készülékeknek; automatikusan kiosztott; 127 a broadcast. LAPD vezérlő mező típusazonosítás + hibadetektálás segítés. 3 (+1) féle keret lehet. Minden esetben a keret 5. bitje jezi, vár e válszt a küldő (poll / final) U keret unnumbered; LAPD felépítés & automatikus TEI hozzárendelés. Lehet: Set Asynchronous Balanced Mode Extended nyugtázott LAPD felépítés kérés Unnumbererd Acknowledgement SABME / DISC nyugtázásra DISConnect LAPD szétkapcsolás, erre csak pozitív nyugta jöhet 10

11 Disconnected Mode Képtelen LAPD kapcsolatot felépíteni, ezt jelzi Unnumbered Information nyugtázatlan információ I keret információs keret. Ha az első oktett legalsó bitje 0, ez jön. Két sorszámot (7 bit) vár. A második oktett legalsó bitje jelzi vár e választ (poll / final). A sorszámok: N(S) adott I kerert sorszáma (mod 128) N(R) a következő várt keret sorszáma (mod 128) és pozitív nyugta az előzőekre UI keret nem külön keret, csupa 0 t tartalmazú U keret, ami automatikus TEI managementre használatos. S keret felügyeleti keret; I keretek vezérlésére való. 3 állapota van: RR Receive Ready = nyugtázás, receive not ready állapot vége RNR Receive Not Ready = átmenetileg foglalat, nem vesz REJ Reject = Baj történt összes N(R) től vett I keret ismétlésének kérése. Automatiuks TEI management TEI... hozzárendelés kérés / jóváhagyás / elutasítás (assignment) ellenőrzés kérés / válasz (check) visszavonás (removal) SAPI = 63 és TEI = 127 (broadcast) számozású UI keretek, referenciaszámmal és üzenettípussal kiegészítve. TEI hozzárendelés menete: Mindig a terminál kezdeményez 16 bites véletlen (nem 0) RN nel indul, broadcastol Ha teljesíthető assigned: ha nem; ellenőrzi biztos nincs e szabad TEI. check eljárás indul, amit a hálózat kezdeményez, ahol RN=0. Konkrét TEI re kérdez rá, aminek a birtokosa válaszol. Ha a válaszokban van 2 azonos RN, vagy TEI elveszi a TEI t (removal), ami egy kétszeresen kiküldött broadcast üzenet. Ha nincs probléma, simán megtagadja a kérést (denied) DSS1 3. rétege LAPD I keretek információsmezőin keresztül bonyolított hívásfelépítés / bontás. Az üzenetek (Information Elements IE) általános felépítése ID + length + value. A kapcsolatfelvétel vázlatos menete: Protocol ID küldése (08H ha DSS1), majd Call Reference, ami magát a hívást azonosítja a későbbiekben is. Ezt követi a Message Type, ami az IE ket azonosítja, megadva ezzel, hogy mit, milyen hosszal kell várni, hogy ebből az érték kivehető legyen. Példák erre: Bearer Capability (átviteli jellemzők) Called / Calling Party Number Beszéd / Adat üzenetek (CS / PS) μ law / A law + user datarate 11

12 Hívásfelépítéskor előszür egy LAPD kapcsolat épül fel (SABME / UA ), majd a következő szekvencia játszódik le: Bontást bármelyik fél kezdeményezhet, itt a Disconnect után a 3. rétegbeli kapcsolat bomlik fel, majd legvégül a LAPD (DISC / UA ) 12

13 SS7 JELZÉSRENDSZER A következőkben a Signalling System No. 7 részenkénti ismertetésére teszünk kísérletet. Az egyes részek logikusan épülnek egymásra, jól párbaállítható a Hálókból ismert OSI modellel: A TUP már nem igazán használt, Az SCCP ISUP közötti lépcsős illesztés jelentése annyi, hogy az ISUP működik SCCP nélkül is, viszont csak egy jelzéshálózaton belül. Az ISUP nak az a része, ami alá beékelődik az SCCP alkalmas több jelzéshálózaton átívelő kommunikációra. Áttekintés gyanánt itt egy SS7 es üzenet, a rétegek feltüntetésével. Itt egy sima (nem SCCP feletti) ISUP üzenet megy át. Az MTP3 mas keret MSG (zöld) részében lehetne SCCP üzenet, afelett TCAP tranzakció (aminek az octetjeit kiírva ASN.1 szerint gyakorlatilag a teljes félév kiférne egy ábrára ) 13

14 ÜZENETTOVÁBBÍTÁS (Könyv 8. fejezet) Message Transfer Part Az SS7 (ld. később) közös csatornás hálózat alsó 3 szintje az MTP k azért felelnek, hogy jelzáshálózaton belül Alice és Bob (akik SP k ) kommunikálhasson full duplex módon is. MTP DATA LINK / LINK LEVEL MTP 1 Jelzéskapcsolat (Data Link Level). 64 kbps korlátozás nélküli, digitális transzparens csatorna. Típusokat és hozzáférési módokat specifikál csak. MTP 2 Jelzésszakasz (Link Level). Hibamentes átvitelt biztosít az információt kiegészíti egy vezérlő jelzéselemmel. Háromféle MTP 2 üzenettípus létezik: Message Signal Unit (hasznos infó ~ LAPD I keret) Link Status Signal Unit (állapot / hibajelzés) Fill In Signal Unit (töltelék, kb. az üzenetek 96% a) FLAG CK info LI FIB FSN BIB BSN FLAG * bit FLAG mindig (itt is van bit stuffing: 5db 1 es után 0) CK checksum info legfeljebb 272 bit, de ez az LI ben meghatározott, ez dönti el,hogy LSSU/FISU/MSU LI hosszindikátor, ha 63 (csupa 1) az értéke, akkor csak típuskód, az üzenet lehet több, mint 272 bites is ilyenkor a záró FLAG alapján található ki a hossz. LI < 63 esetén a tényleges hosszt mutatja. További fontos értékei LSSU esetén. Busy torlódás Processor outage ellenoldallal nem lehet kommunikálni a 3. / 4. szinten Out of service egyéb hiba. Out of alignment túl hosszú üzenet, túl sok 1 es egymás után Normal / Emergency alignment 2 16 octet szinkronizáláshoz1 FIB előre indikátor bit. Ha invertálódik, akkor egy korábban elküldött, de újra kért üzenetet ismétlünk. BIB hátra indikátor bit. Ha invertálódik, akkor negatív nyugtát küldünk, az adó ismételni fog. 14

15 FSN Forward Sequence Number, küldött jelzéselem sorszáma. BSN Backward Sequence Number, az utoljára helyesen vett jelzéselem sorszáma. HIBAJAVÍTÁS MTP 2 ALATT Basic Error Correction 8000 km nél rövidebb szakaszok esetére. Az MSU kat FSN ben sorszámozza, BSN nel ellenőrzi, hiba esetén a BIB bel jelez, ahol invertált FIB et tapasztal ott kapja vissza az újrakért adatot. Preventive Cyclic Retransmission nagy késleltetések esetén: nincs (const 1) FIB és BIB, sorban küldi a jelzésüzeneteket, amint vége a sorozatnak, akkor kezdi újraküldeni a nem nyugtázottakat. SIGNALLING NETWORK LEVEL MTP 3 Két funkció: tetszőleges jelzéstovábbítás (SMH), szükség szerinti hálózat újrakonfiguráció (SNM). A jelzésüzenetek MSU t szállító MTP 2 jelzések. Címzés Signalling Point Code 14 bites számok csak egy hálózaton belül egyértelmű, afelett a hierarchia magasabb elemei oldják meg. Nemzetközi változata az International SPC, ami áll: 3 bit zoneid ből 8 bit Area Network code ból 3 bit országos nemzeti KP jelzőből National Regulatory Authority pl. NMHH meghatározza a jelzéspont kódokat. 9 biten azonosítja a szolgáltatókat, 5 biten az ISPC t. Lényege, hogy szolgáltató és kormányfüggetlen. MTP címzési formátum szokványos MSU üzenetet szállító MTP 2 jelzés, a FLAG, CR LI, FIB részek a megszokottak az előbb info val jelölt bitek felépítése a következő: RL MSG SIO SLS OPC DPC < SIF >< SIO > Bővebben: MSG minimum 1 byte; hasznos üzenet SIO+SIF mértete sum. min. 6 byte. 15

16 RL (Routing Label): SLS (Signalling Link Section) több lehetséges útvonalból választ egyet (4 bit) OPC (Originating Point Code) feladót azonosítja (14 bit) DPC (Destination Point Code) a címzettet azonosítja (14 bit) SIO (Service Information Object) Hálózat & szolgáltatás indikátor, megadja pl. a formátumokat, üzenettípust, protokollokat. JELZÉSHÁLÓZAT MENEDZSELÉS Signalling Link Management méri a hibaarányt, ebből jelent a management felé. Signalling Traffic Management nyilvántartja a jelzésszakaszok állapotát, szükség szerint módosítja az irányítótábláját. Signalling Route Mangement végrehajtja és továbbterjeszti a menedzsment által meghatározott változtatásokat. NEMZETKÖZI HÍVÁSFELÉPÍTÉS Topológia Az egyes nemzeti jelzéshálózatok Gateway Signalling Pointokon keresztül csatlakoznak a nemzetözi jelzéshálózatokhoz. A nemzeti SP k címe az NSPC, a GSP knek (mivel két hálózatnak is a részei) van NSPC je és ISPC je is. A címzést tovább segíti a Network Indicator (NI), ami a hálózatokat jelöli ki. Jelzéspont kód formátumok Feladatoknál lehet fontos a helyes formátum. Nemzeti hálózaton belül háromjegyű szám (555), nemzetközi hálózatban tagolt ( ). Az NI értékek és a szolgáltatók kódjai (SI) kétjegyű számok. A hívásfelépítés menete A hívó SP je fogadja a tárcsázott számot. A központ detektálja, hogy nemzetközi hívásról van szó. Foglal egy áramkört a GSP felé. A kezdeményező központ küld egy ISUP IAM üzenetet a GSP felé a nemzeti hálón belül még SIO ban a hálózatindikátor ezt mutatja. GSP feldolgozza a beérkezett hívást. A GSP n belüli központ eldönti a milyen nemzetközi útvonalra lesz szükség és le is foglal egyet. A hazai GSP küld egy IAM üzenetet a célország GSP je felé ennek a SIO ja a nemzetközi jelet tartalmazza. 16

17 A célország GSP je feldolgozza a kérést, megkeresi a hívott központot, útvonalat foglal hozzá és IAM üzenetet küld a SIO itt ismét nemzeti hálózatot mutat. A továbbiakban a fent használt útvonalon fognak haladni a jelzések. Tanulságok nem közvetlen a kapcsolat a két végpont között, mivel nem egy hálózatban vannak. (Ilyen definíció szerint nem is lehetne). Mindig az SP k, GSP k központjai döntenek, a végpontok nem rendelkeznek topológiai ismeretekkel. A kommunikáció során tehát a SIO k hálózatonként, a DPC k, OPC k központonként változnak. ISDN USER PART Funkciói MTP feletti, felhasználói réteg, külön interfésszel az MTP felé. MTP Hívásfeldolgozás vezérlés hívásvezérlés MTP Áramkörfelügyelet vezérlés hívásvezérlés hívásvezérlés Üzenetküldés vezérlés MTP hívásvezérlés Üzenet elosztás vezérlés MTP Keretezés az MTP 3 SIF kereten belül, fentebb MSG blokkal jelölt, minimum 1 byte hosszú szegmensbe kerül az ISUP üzenet. Felépítése: + + CIC ciruit information code beszélgetést azonosít + + MT üzenettípus fix paraméterek PTR PTR PTR nem fix paraméterek, hossz c érték pointer unboundvar.vals nem fix paraméterek + + unboundvar.vals EOP (0) end of optional part csak szekvenciális kiolvasás + + Paraméterek típusai Optional szituációfüggően sokféle lehet (ami biztos: type, length, value) pointerrel mutatott Mandatory Fix hosszúságú Változó hosszúságú 17

18 ISUP JELZÉSEK ISUP jelzések osztályozása ~ ISUP funkciók Hívásfelépítési, felügyeleti, elbontási (IAM, REL, ACM ) Felépített hívás módosítási Áramkörfelügyeleti Végpont végpont üzenetek IAM (Initial Address Message) Első címüzenet, ami lefoglal egy áramkört és szállítja a hívott számot (több részletben overlap, vagy en bloc ekkor a Subsequent Address Message is kell). Az overlap módszer gyorsabb, de bonyolultabb. IAM paraméterek: Nature of Connection földi / sat link kell e folytonosságvizsgálat echot melyik oldal kezeli Forward Call Indicators hívásfelépítéshez szükséges jelzésrendszeri követelmények. Calling Party s Cathegory hívó fél típusa, adat e, prioritás, nyelv Transmission Medium Requirement híváshoz szükséges áramkör típusa (analóg / digitális / korlátlan ) Called Party Number Calling Party Number opcionális Address Complete Message (ACM) ha minden tárcsázott számjegy megérkezett, akkor teljes a cím, indulhat az útkeresés. Tartalmazza, hogy milyen jelzésrendszert kell használni, ki kezel echót és hogyan kell számlázni. Sosem megy ki CPG üzenet nélkül. Call Progress (CPG) Hívás folyamatban paraméterei megegyeznek gyakorlatilag az ACM ével. Answer Message (ANM) akkor küldődik, ha a hívott fél fogadja a hívást. Release (REL) bontási üzenet, tartalmazza a bontás okát és az információkat az esetleges hibáról. REL üzenetek esetén a CIC kódok különbözhetnek. Fontos eltérés az ANM üzenetektől, hogy ha több központon át folyik a hívás, akkor a bontások visszaigazolása történhet párhuzamosan, míg az ANM ek megvárják egymást: 18

19 ANM esetén A O B \ \ \ \ / / / / REL esetén A O B \ \ / \ / \ / / Többszörös hívásátirányítás ha nincs válasz akkor, a központok továbbítják a hívást a megadott végberendezés felé. Paraméterek, üzenetek: Call Forwarding Unconditional feltétel nélküli átirányítás Call Forwarding Busy foglalt üzenet Call Forwarding No Reply nincs válasz üzenet 19

20 Áramkörfelügyeleti jelzések Áramkörök vezérlésér szolgáló üzenetek: Áramkör ki / bekapcsolás: BLOcking / BLocking Acknowledgement UnBLocking / UnBlocking Acknowledgement Folytonosságvizsgálat: Continuity Check Request kimenő központ kéri a vonalra LooPBack Acknowledgement Message bejövő központ visszahurkolja a vonalat kimenő központ erre ad vizsgálójelet (teszthang) COnTinuity Message tájékoztatás a vonalvizsgálat eredményéről JELZÉSKAPCSOLAT VEZÉRLŐ EGYSÉG (SCCP) Signalling Connection Control Part globális címen (GT) alapuló jelzésüzenet irányítás, kapcsolatnélküli esetre is. Gyakorlatilag meghatározza a globális címből a cél jelzéspontok kódját ha adott hálózaton belül van. Ha más hálózatban, akkor az oda vezető Gateway SCCP jelzéspont kódját tudja. 20

21 Nemzetközi hívás SCCP vel A hívó ország MSC je a hívott készülék hívószámát (MSISDN = 18) véve meghatározza a célországot, majd a SCCP nek (aki a nemzetközi kapu, a GSCCP felé továbbít majd) továbbadja az MSISDN t Az üzenet DCP je a GSSCP jelzéspont kódja (=33); a hálózatindikátor nemzeti. A hazai GSCCP a hívott MSISDN jét vizsgálja tovább, ez alapján tudja merre kell a célország felé küldeni. A hazai GSCCP elküldi a nemzetközi hálózaton (indikátor nemzetközi) az üzenetet. A DPC itt a célország GSCCP jének jelzéspont kódja(=20 1 1) (más néven ISPC) A célország GSCCP je a kapott MSISDN alapján kinézi a saját országa HLR jéből a hívott jelzéspont kódját (HLR = 10 MSISDN = 18) Ez után a nemzeti hálózaton a HLR en keresztül találja meg a hívott eszközt. Különbség az ISUP tól az, hogy nem szakaszonkénti a hívásfelépítés. Az MTP k számára transzparens módon valósul meg a felépítés. Továbbá lehetőség nyílik a különböző funkcionális alrendszerek (VLR, EIR, AuC ) külön kód szerinti megkülönböztetése. Kapcsolat nélküli SCCP szolgáltatás A HLR, VLR adatainak lekérdezésére alkalmas, az üzeneteket Unidata (UDT) formában küldi, melyek megegyeznek az ISUP formátummal, 21

22 egyedül CIC kódot nem tartalmaznak. Tranzakciók azonosítását nem támogatja; csak az SS7 en belüli alrendszereknek tud transzparensen üzenni. Kapcsolatorientált SCCP szolgáltatás képesség jelzéskapcsolat felépítésére és bontására. Működése: CR Connection Request {Source Local Reference} CR Connection Request {Source Local Reference; Destination Local Reference} DT DataForm {Destination Local Reference} DT DataForm {Destination Local Reference} RLSD Released {Source Local Reference; Destination Local Reference} RLC Release Complete {Source Local Reference; Destination Local Reference} A kezdő SLR ( ) és a záró DLR ( ) megegyezik; ekkor van vége a kapcsolatnak. TRANZAKCIÓS KÉPESSÉGEK FELHASZNÁLÓI EGYSÉG Felépítés, szerep a Transaction Capabilities Application Part az SCCP által biztosított kapcsolat felett hajt végre tipikusan adatbázisműveleteket. Eredetileg a GSM igényeire fejlesztették (pl. HLR & VLR műveletek), de funkcionalitása ennél bővebb. Műveletek elvégzése TCAP segítségével a művelet (tranzakció) lényege, hogy egy távoli objektumon operációt hajtunk végre. Ehhez szükséges: A tranzakció azonosítása A tranzakción belüli művelet azonosítása (sorszámmal) A művelet típusának azonosítása Minden művelet komponensekből áll; minden komponens tartalmaz egy azonosítót (ez a fentebbi sorszám) Minden komponenshez rendelhető egy üzenet, ami három részből áll: Tranzakciós rész [Dialógus rész opt] Komponens rész Tranzakciós rész azonosít egy tranzakciót és azt, hogy az éppen hol tart (ha több üzenetben megy át a tranzakció). Üzenetei: Begin kezdeményez, azonosítót ad: Originating Transaction IDentifier 22

23 End utolsó üzenet, a fogadó oldal küldi Destination Transaction IDentifier, megegyezik a Beginben kapott OTID vel. Continue ha összetettebb a tranzakció akkor End helyett Continue jön; majd a folytatásban Continue helyettesíti a Begint. Az OTID DTID kapcsolat a szokásos. Abort érvénytelen üzenet, fatal error tartalmazza a helyet és az okot. Dialógus rész meghatározza a verziót és a használt, magasabb szintű protokollt. Opcionális, mert egy jelzésszakaszon a TCAP verzió mindig ugyanaz, elég egyszer megadni, tipikusan az első üzenetben van dialógus rész. Abort üzenet esetén itt van a hibaok és hely. Komponens rész egy, vagy több komponenst tartalmaz képes több műveletet kezelni. Komponens tartalma: tranzakción belüli azonosító (egy octet, azért mert több művelet is lehet a tranzakción belül) művelet azonosítója a magasabb szintű protokoll határozza meg. művelet paraméterei végrehajtás fázisa Invoke indítás Begin tranzakciós üzenet Return Result Not Last több üzenetből álló műveletnél a nem utolsó válaszok End tranzakciós üzenet Return Result Last több üzenetből álló műveletnél az utolsó válasz End Return Error hiba, pl rossz PIN kód End Reject ismeretlen kérés, vagy ismeretlen válasz, vagy értelmezhetetlen... PROTOKOLLTECHNOLÓGIA - ELMÉLET (Könyv 2-3. fejezet) Protokoll kommunikációs szabályokat ír le a hálózatban adott eszközök, entitások között. Interfész két réteg határán átvezető felület, kapu, port Két részből áll: Service Access Point Abstract Service Point Protokollok előállítása Főbb lépései: Specifikáció emberi nyelv use case. Egyértelműség. Teljesség. Megvalósíthatóság. Ellenőrizhetőség. Formal Description Technique definiált szintaxis & szemantika, state chartok. Validálhatóság. Verifikálhatóság. Implementáció load, performance & conformance test 23

24 Szimuláció Protokollspecifikáció mindig: teljes, minden követelményt tartalmaz egyértelmű, mindenki ugyanarra gondol ha olvassa ellenőrizhető megvalósítható, a lehető legegyszerűbben Az, hogy ez a 4 feltétel teljesüljön formális leíró módszerekkel biztosítható. Ezek fordíthatók emberi nyelvből szabályok szerint automatikusan feldolgozhatók lesznek. Pluszkövetelmények ahhoz, hogy telco nak megfelelő legyen egy specifikáció: párhuzamos események leírhatósága nemdeterminisztikus folyamatok leírása (~forgalom, stb ) real time előírások (késleltetés pl.) adatstruktúrák, adatelemek (Protocol Data Unit) definiálása rétegek megjeleníthetősége Véges automaták Finite State Machine Avagy a modellezési modellek. Legfőbb tulajdonsága, hogy determinisztikus, vagyis teljes, vagyis minden üzenettípusra adott az állapotátmenet. Kötelező elemek: Állapotok Kezdőállapot Üzenetek Átmeneti függvények: állapot; üzenet új állapot; új üzenet Extended Finite State Machine Mivel az FSM valós protokollok esetén nagyon sok állapotot tartalmazna, megjelennek még 24

25 Belső változók az ismétlések miatt Predikátumok (=feltételek) Eseményel (értékek változása): állapot; üzenet; predikátum új állapot; új üzenet; új predikátum Communicating Extended Finite State Machine Kiterjesztés: nagyobb egységek (EFSM ek) egymás között kommunikálnak Gráf, vagy háló alapú leírások Petri háló: O connection I execution, ezek elsüthetők (fire). token, absztrakt üzenet ami a tokent kiküldi Ha minden feltétel adott, végrehajt: Ezeknek a leírásoknak azonos a kifejezőereje például az CEFSM nel, de a gráfokon a deadlock, vagy a párhuzamosíthatóság könnyebben detektálható. Cél lehet az áttekinthetőség kedvéért az állapotszám csökkentés, erre lehetőség több token vagy színezett tokenek vagy paraméterezett tokenek vagy időzített tokenek alkalmazása. Calculus of Communicating Systems Van egy megfigyelhető pont (Point of Control and Observation), ahonnan az üzenetek és a rájuk adott válaszok figyelhetők meg ez írható le formálisan. ADATSPECIFIKÁCIÓ - SDL - INRES (Könyv 3. fejezet) 25

26 Adatspecifikáció kiegészítő elem a viselkedési és szerkezetleírók mellé. Általánosan leírja, hogy a PDU k, üzenetek struktúrája milyen, különböző megkötéseken keresztük. Különösen fontosak az absztrakt adattípusok. Ezek nagyon hasonlítanak a C++ ból, Javaból ismert osztályokra, ugyanúgy definiálnak adattípusokat, struktúrát és akár műveleteket is SDL A Specification and Description Language véges automatákon alapul, grafikus változata is van. Elemei: A System, a rendszer amit definiálni kell, ennek vannak bemenő és kimenő jelei, kezdeti, kimenő és végállapota. A System blokkokra oszlik, melyeket csatornák kötnek össze. A blokkon belül pedig processzeket kötnek össze jelutak: A jelek definiálására külön box szolgál, különben zavaros lenne az ábra: 26

27 A processzek az érkező jeleket (amik még nem kellenek) FIFO sorban várakoztatják; akkor fogy egy jel a sorból, ha input szimbólum érkezik. Ha váratlan jel jön, eldobja ha várt, akkor OK. A processzek egyenrangúak, működhetnek párhuzamosan. Lehet dinamikus, vagy statikus, ha dinamikus, akkor terminálható. Az állapotok közti átmenetek leírására is grafikus lehetőség (folyamatábra) adott: 27

28 A fenti példa egy időzítő, amit beállítunk egy fix értékre (3), majd vizsgáljuk lejárt e. Ha lejárt töröljük az értékét. Ugyanez a folyamat szekvenciadiagrammon: INRES INitiator RESponder protokoll, csak demonstrációra jó; lényege, hogy a kezdeményező inicializálja a kapcsolatot, a válaszadó pedig vagy válaszol, vagy eldobja a csomagot. A PDU kat a közegen (medium) továbbítja, kapcsolatorientált adatátvitellel. Fázisok: Kapcsolatfelépítés initiator kezdeményez Connection Request PDU val, melyre a pozitív válasz a Connection Confirmation, a negatív a Disconnection Request. Adatátvitel initiator kérheti; Data Transfer üzenettel. A responder AcK kal válaszol. Ha sokáig nem jön ACK, akkor bont. Az adattovábbítás sorszámozott, mindig az ACK olt után közvetlenül következőt küldi a küldő. Bontás DR esetén a felhasználók felé is továbbítódik a bontás vége a kapcsolatnak lehetőség nyílik újat kezdeményezni INRES megadása SDL ben Az INRES system három blokkot tartalmaz: INI (initiator) MEDIUM (közeg) RES (responder) ezek rendre így vannak kétirányú összeköttetésekkel ellátva. A system két kimenet a kezdeményező / válaszoló user felé mutat. A blokkok közötti jelek (CR, CC, DR, DT, AK) külön signal boxban definiáltak, sorszámnövelő operátorral, adatszerkezettel együtt. 28

29 A blokkokon belül két processz szükséges mivel az INI és RES blokkok maguk is egyfelől a közeggel, másfelől a felhasználójukkal állnak kapcsolatban. A felhasználó felé szól az initiator/responder process, a közeg felé a coder process, melynek feladata a közegfelhasználáshoz szükséges kódolás/dekódolás. >>> Az INRES protokollhoz elérhető egy demó itt. <<< ASN.1 Abstract Syntax Notification One Adatspecifikációs nyelv, PDU k alapjait, struktúráját írja le. Négyféle kódolási szabály (Encoding Rule) használt: Basic Canonical Distinguished Pegged rádiós interfészekhez, nagyon kompakt forma. Fontos tulajdonsága, hogy case sensitive, a beépített típusok NAGYBETŰSEK, a Modul és Típusnevek nagybetűvel kezdődnek, az egyedi adattípus értékek kisbetűvel kezdődnek mindig. ASN Típusok A típusok mérete akkor amekkorára kódoljuk, a fennmaradó helyeket 0 val tölti fel. Főbb beépített típusok: INTEGER BOOLEAN REAL BIT_STRING pl B OCTET_STRING pl. AB18 O IA5String ASCII kódolás Konstrukciós szabályok Struktúrát meghatározó típusok adottak: SEQUENCE különböző típusú elemekből álló rekord SET különböző típusú elemekből álló halmaz (vagyis itt a sorrend se számít) A SET OF és SEQUENCE OF azonos típusú elemeket tartalmaz rendezetten CHOICE többféle mezőt sorol fel, amiből egy időpillanatban csak egyet tartalmazhat. Az egyes mezők megadása mindig kötelező, kivéve ha a típusnév után szerepel az OPTIONAL kulcsszó. A típusokból korlátozásokkal subtype ok hozhatók létre; ezek az értéktartományt szűkítik le: Otnel_kisebb szamok ::= INTEGER(0..4) Int_tomb_1_16_elemmel ::= SEQUENCE SIZE (1..16) OF INTEGER Felsorolas ::= IA5String(FROM(( 2 3 A & )) 29

30 Modulok egy modulban logikailag összetartozó típusokat helyezhetünk el és szabályozható, hogy ezekből kívülről mi legyen elérhető (IMPORT/EXPORT). A kötelező részben definíciókat tartalmaz, a fentebb ismertetett típusokból. Pl.: Probamodul DEFINITIONS ::= BEGIN IMPORT MasikModul EXPORT definitions Adat ::= SET{ } END Kódolási szabályok Avagy mi megy ki a vonalra. A következőkben a BER szerinti szabályok kerülnek ismertetésre. Alapvetően háromféle információt kell elküldeni, ez pedig a típusazonosító (tag), hossz (length), érték (value). Egymásba ágyazott üzenetek esetén a value alatt helyezkednek el rekurzívan az újabb üzenetek: TAG HOSSZ TAG HOSSZ ÉRTÉK TAG HOSSZ ÉRTÉK < ÉRTÉK > < ELSŐ MEZŐ >< MÁSODIK MEZŐ > TAG Ez kódolva adja meg az üzenet típusát. Állhat egy, vagy több octetből. Egy TAG en belül három mező van: class (C) (felhasználás szerint: univerzális, alkalmazás, környezetfüggő, vagy egyedi) format (F) (ha nincs value ba ágyazott üzenet: egyszerű = 0, különben összetett = 1), tag érték (val) C C F val val val val val Hosszkódolás Három lehetőség van: hossz <= 127: rövid forma első bit 0, majd 7 biten a hossz. hossz > 127: hosszú forma első bit 1, majd 7 biten a hossz hossza, végül jön a hossz több octetben annyiszor 8 biten amennyin kifér. összetett üzenet (TAG 3. bit (F) = 1): indefinit forma [ ] nem mondjuk meg a hosszt, csak két csupa 0 octettel jelezzük a value végét. Hogyan kell egy elég összetett üzenetet kódolni? Aki nagyon lelkes, az nézze meg ezt. 30

31 Legyen az üzenet egy SET: pelda ::= [5] SET { a INTEGER, 3 b [1] INTEGER, 3 c [2] IMPLICIT INTEGER, 3 d [31] OCTET STRING, 128 db FF e [4] IMPLICIT BIT STRING, 111 B f [5] IMPLICIT BOOLEAN, TRUE g NULL h [10] INTEGER DEFAULT 0 nem kell küldeni! } Első elem a peldaami egy 5 ös típusértékű. Összetett típus, ezért a hossza indefinit megadható. A value mező tartalma pedig az összes többi hátralévő üzenet: A SET definiált típus, viszont jócskán összetett ezért ismét indefinit megadható a hossza. A value mező tartalma pedig az összes többi hátralévő üzenet: ainteger, definiált típus, hossza egyszerűen megadható értéke 3. Közvetlenül követi a következő mező: binteger TAG értéke 1 összetett, vagyis indefinit a hossza. A value tartalma egy egyszerű INTEGER TAG, melynek hossza egyszerűen 1, értéke pedig 3. A value t közvetlenül követi két csupa null octet. cimplicit integer. Az implicit jelentése szerint nem küldi ki az igazi típust, a formátum az IMPLICIT kulcsszó utáni formátum lesz, a TAG értéke pedig az IMPLICIT kulcsszó előtti szám. d octet string, aminek per definitionem 31 a TAG value ja pont nem fér ki 5 biten (az a hosszú formátumra utal már!) ezért 2 TAG kell. A típus összetett is, vagyis indefinit a hossz, a value ban pedig következik egy octet TAG, majd mivel 128 db FF értéket kell átadni, két hosszmezőre lesz szükség: az első megmondja, hogy kell még egy hosszmező, a másodikban pedig 8 biten kódoljuk a 128 at. végül komolyan következik 128 db FF octet. A value t közvetlenül követi két csupa null octet. eimplicit bit string 4 es értékű TAG mezőt követ egy 2 értékű hosszmező. Azért 2, mert kell egy counter octet ami megmondja hány bit nem hasznos része a value nak. Végül a value tartalmazza (balról kezdve) a bitmintát. f5 ös TAG értékű, egyszerű bool változó, ahol a az érték egy db 1 es. g5 ös TAG értékkel egy 0 értékű hossz octet. Ezt követi kétszer két csupa null octet, ami a peldaés SETlezárása. Jobban érthető minden egy ábrával. A Piros, narancs, kék és világoskék keretek az összetett value kat szemléltetik. A d mező kivételével minden mező octetjei egy sorban vannak 31

32 TESZTELÉS (Könyv 5. fejezet) Teszttípusok Az elkészült protokoll implementációk tesztelését több szempontból is el kell végezni: konformancia teszt ha azt vizsgáljuk, hogy valóban azt csinálja e, amit a specifikáció előír statikus tulajdonságokra: üzenetek szerkezete, spec. szerint kötelező képességek implementáltsága dinamikus tulajdonságokra: működés közbeni vizsgálat; adott jelre megfelelő e mindig a reakció interoperability teszt ha azt vizsgáljuk mennyire képes együttműködni a környezetével performance azt vizsgáljuk mekkora a teljesítőképesség, mekkora forgalom esetén milyen válaszidőket produkál, stb Fontos még a teszt mélysége, ami sorrendben lehet: Basic Interconnection Test minimális követelményeket ellenőriz, nagyon alap interconnetctiont vizsgál, előszűr. Capability Test megnézi a megvalósított obektumban a statikus tulajdonságokat és képességeket, a tesztesetek egy részhalmazát futtatja. Behaviour Test nagyjából minden követelményt ellenőriz amennyi még kivitelezhető időben és gazdaságos Conformance Resolution Test specifikáción túlmutatva azt is nézi, hogy nem szabványos eszközökkel/elrendezésekkel milyen válaszokat ad. 32

33 A tesztelés három legfontosabb követelménye, hogy legyen: 1. Repeatable azaz megismételhető 2. Comparable azaz összehasonlítható más esetekkel 3. Auditable azaz dőljön el belőle, hogy jó e az eszköz. Baj még az, hogy ha a teszt kimenetetle nem várt volt (unforseen). Tesztelés elvi felépítése a teszt lényegében a tesztelés alatt álló egységen (Implementation Under Testing) futtatott tesztesetek megyfigyelése a Point of Control and Observation on (Ez az IUT bemenetét (control) és kimenetét (observation) jelenti). A megyfigyeléseket ítélet(ek) követik: Pass sikeres; minden a szabályok szerint történt Fail konformancia sérült Inconclusive a cél nem teljesült, de lehet, hogy alsóbb rétegbeli hiba miatt pl. Maga a teszteset is lehet hibás, ha szándékosan rossz a formátuma (invalid), vagy ha az üzenet jó, csak rosszkor érkezik (improper). Megvalósítás lépései folyamat és kimenetelek: Protocol Implementation Conformance Statement Protocol Implementation extra Info Testing A tesztek két szintje: Abstract Test Suite Executable Test Suite Teszt után kitöltendő: System Conformance Test Report Protocol Conformance Test Report 33

34 Szabványos tesztelrendezések Alapvetően négyféle metódus definiált, ezek a tesztelésben részt vevő rétegek számában és a megfigyelési pontok elhelyezkedésében különböznek: Lokális a tesztelés ha az adott környezetben folyik: Elosztott a felső rétegbeli teszter az IUT ben (vagy legalább a tesztelt rendszeren belülre) kell elhelyezni a felső interfészből közvetlenül megfigyelhetők a történések: Koordinált lényegében ugyanaz, mint az elosztott, csak a felső teszter és az IUT egybeépített; vizsgálható az alsó és felső teszterek együttműködése is. Távoli ilyenkor nem feltételezzük felső teszter létezését csak az IUT n keresztül küldött üzenetek alapján hozható ítélet. További szempont a PCO elhelyezkedése az SUT hez képest: aktív ha egyazon hálózatban tartózkodnak, passzív, ha a PCO kívül van és csak belehallgat a hálózatba. Test Case készítés 34

35 Alapból a cél az, hogy megírjuk őket és lefuttassuk minden eshetőségre ennek a karbantarthatósága nehéz Erre kínál megoldást a Model Based Testing. Eszerint egy teszt Exhaustive ha az IUT helyes, akkor minden esetben PASS az ítélet Sound ha minden hibás működés detektálható Complete ha egyszerre Sound és Exhaustive. A teszt ebből a szempontból esemény sorozatokból áll, melyek fában reprezentálhatók; a levelek pedig a kimenetek [ítéletek]. eddig tartott a ZH (2013/14/2.) A TTCN NYELV (Könyv 5.2. fejezet + Ericssonos diák) A TTCN már a 3. verziójánál tart; feloldása eredetileg Tree and Tabular Combined Notation, később lett Testing and Test Control Notification. Protokollimplemetációk tesztelésére való programozóközeli nyelv es ETSI ben definiált. Van táblázatos, grafikus és prezentációs (userközeli) formátuma. Hierarchia A tesztsorozatok hierarchikus rendben leírhatók: Modulok A modul a legfelsőbb szintű egység, egy teszt is egy, vagy több modulból áll. Lehetnek paraméterei és attribútumai is: module modulename [objid objectid] { Definitions & Control part } [with { attributes } ] 35

36 A modulokon belül két rész van: Definitions part globálisan elérhető definíciók: Modulparamérerek külső paraméterek, amik futtatás közben tesztelhetők Adattípus definíciók a tesztadatok definiálására Portok és komponensek a tesztkonfiguráláshoz Függvények, Tesztesetek, stb a dinamikus viselkedés leírásához. Control part control {} blokkon belül ez indul el először futtatáskor, tartalmaz: Lokális definíciókat; a változók értékeit, időzítőket. Teszteseteket lehet innen futtatni és vezérelni A modulokba importálhatunk definíciókat más modulokból, de ez problémás lehet nagy tesztek esetén (legacy kódok ) import frommymodule all; HelloWorld module MyExample { type port PCOType_PT message { // port a kommunikációhoz inout charstring; } type component MTCType_CT { // ez fog futni port PCOType_PT My_PCO; } testcase tc_hellow () runs on MTCType_CT system MTCType_CT { map(mtc:mypco, system:mypco); My_PCO.send ( Hello, world! ); setverdict (pass); } } control { execute ( tc_hellow() ); // tényleges indítás } Adattípusok Eredményekre, tesztelésre optimalizált típusok: Hagyományos (string)típusok: integer float boolean objid (objektumazonosító) verdicttype {none, pass, fail, error, inconc} bitstring hexstring universal charstring 36

37 Speciális típusok architektúrát leíró: port engedélyezett üzenetváltások tesztkomponensek között component leírja mely portok vannak komponenshez kötve address komponensek összekötésére default referenciát tárol activate és deactivateműveletekhez Strukturált típusok (SS7 mezők lefedhetők velük) record elemek rendezett sorozata record of adott típusú elemek rendezett sorozata set rendezetlen lista set of adott típusú elemek rendezett sorozata union felhasználó definiált absztrakt container, melyből egy elem választható. Például egy HTTPMessage union kétértékű lehet: vagy request vagy response. type union HTTPMessage { bitstring REQUEST, bitstring RESPONSE } if (ischosen(httpmessage.request)) { } Értékek hozzárendelése: var MySetType v_myset1 := { field2 := true, field1 := omit // nem jelenik meg } Az omit kulcsszót akkor kell használni, ha egyébként nem lekötött optional mezőt definiálunk. Az <unbound>kulcsszó egyelőre inicializálatlan értéket jelent. Fontos az is, hogy minden létező mező ki legyen töltve valamilyen módon (omit, unbound, vagy (=not used) legyen!). Az értékek egymásba is ágyazhatók strukturált típusmezők hozhatók létre, amik a specifikáción kívül bárhol elérhetők a. jelöléssel: v_myset1.field2 = 4 Indexelni a []operátorokkal lehet, egyszerre csak egy számot írva közéjük Strukturált típusok Az enumeratedkulcsszó egy listából választ, az egyes elemekhez rendelhető egy integer (sorrend) is. Az integerek kézi hozzárendelésekor az üresen hagyott elemeket a TTCN kitölti 37

38 a megfelelő, sorrendet kitöltő számokkal. Az integerek különböző sorrendű hozzárendelése akár teljesen azonos enum okhoz is különböző típusokat eredményez ( inkompatibilitás). A child definiálható egy parent részhalmazaként, lényeg hogy mindkettőnek (és a gyökerüknek is) azonos legyen a típusa. Megkötések Többféle megkötés, szűkítés alkalmazható: Érték: type integer TipusomSzukebb (1.. 18);1 és 18 közötti integer. infinitynem használható! Hossz: type record length(9.. infinity) of integer PeldaInt egy legalább 9 hosszú integerekből álló rekord. Minta: charstring vagy universal charstring esetén megadható minta, ami engedélyez bizonyos értékeket wildcardok alapján: type charstring MyString (pattern a*d?f ); Erre illeszkedik a + bármiből bármennyi + d + egy bármilyen char + f pl. abcdef. Informatívabb változónevek, aliasok definiálhatók: type MyType Myalternativename; Konstansok, változók, paraméterek A változók láthatóságára 7 szint definiált a TTCN ben: module globális control modul kontroll része, innen kilátni a modul felé block { } törzs function altstep testcase component Egy TTCN 3 modulon belül bárhol definiálható konstans. Jelölési konvenció: c_ vel kezdeni a konstans változók neveit. Szintén beágyazható: const OsszetettTipus c_ossz1 := { field1 := aaa, field2 := { field21 := xxx, fielf22 := 5 } } Változó (variable) csak control, testcase, altstep vagy function blokkon belül definiálható, globális változók a moduldefiníciós részben nincsenek. Változó a var kulcsszóval definiálható. 38

39 Tömb (array) egyszerre adható meg a méret és az indexelés tartománya. Példák: [3..5]tömb aminek az első eleme [3] mal, az utolsó az [5] tel indexelhető [7]sima 7 elemű tömb. [8][8]2D tömb Modulparaméterek Tesztkörnyzeteben, vagy configfájlból megadható az értéke, a teszt során konstans marad. modulepar integer tsp_myparam1 := 0 // default érték éremes ilyet adni! ha nincs, akkor a configfile ban kell legyen Operátorok és programvezérlés Nagyon hasonlít a c++ hoz, a teljesség igénye nélkül: vezérlés: if select case else for while do label goto break continue operátorok (precedenciasorrendben, unáris, bináris): () + * / + & not and << < == not Timerek Bárhol engedélyezett a definíciójuk, opcionálisan időtartam is megadható: timer T1 := 1.0;.start tal indítható, ami után a háttérben fut. Ha lejárt keletkezik egy event, erre vár a timeout (ami után a rendszer blokkol). A.readfügvénnyel kérdezhető le a pillanatnyi értéke (ha 0 akor inaktív). Tesztkonfiguráció Az IUT black box; környezetben kell vizsgálni tesztkonfiguráció, melynek feladata elhitetni az IUT vel, hogy valós környezetben van. Az ábrákon dobozok (komponensek) kommunikálnak portokon (interfészek) keresztül: 39

40 Portok A portokon fullduplex (in out inout) kommunikáció valósul meg, a megadott típusokra (pl.: integer octetstring) korlátozottan. Így: type port EnyemPortTipus message // message mert üzenetalapú { in ASP_RxType; inout integer, octetstring; } Komponensek Három fő fajta a Main Test Component (automatiukusan generált, fő tesztkomponens), system, Parallel Test Component (bárhány létrehozható). Áll portokból, definíciókból és timerekből. type component MyComponent_CT { port PortTipus_PT BE; port PortTipus_PT KI_Array[5]; const bitstring c_myconst := 1111 B; timer T_MyTimer := 1.0; } Függvények 40

41 A komponensek viselkedését és magukat a teszteket is függvények segítségével lehet leírni. Definiálhatók modulokon belül/kívül, komponenshez kötve vagy szabadon. Részei: függvényazonosító ez a neve, ezzel hivatkozható header: paraméterlista (in) inouttal is megoldható, de az lassabb... runs on komponens, amihez kötjük return visszatérési érték típusa (out) Lokális definíciók Viselkedés leírása A testcase egy speciális fajta függvény, ami mindig az MTC n fut. Az execute()utasítással indíthatók ha nem automatikusan futtatja az MTC. control { v1_myverdict := execute(tc_testcasename(), 5.0); // timeout // megadva module MyModule { testcase tc_mytestcase1() runs on MyMTCType_CT system MYTestSystemType_SCT { } } } testcase tc_mytestcase2() runs on MyMTCType_CT system MYTestSystemType_SCT { } Ítéletek (verdict) verdicttype beépített típus, lehet modulparaméter, konstans vagy változó, általában egy execute()eredményét tárolják. Vannak továbbá minden MTC / PTC komponensben built in verdictek, melyek a setverdict() és getverdict tel manipulálhatók. Tartozik a verdictekhez egy logika ami szerint a részeredmények befolyásolják (felülírják) a végleges verdictet (azaz pl. egy PTC error eredménye az egész MTC esetében errort ad). Rész Végső none pass inconc fail error none none pass inconc fail error 41

42 pass pass pass inconc fail error inconc inconc inconc inconc fail error fail fail fail fail fail error Konfigurációs műveletek A TTCN 3 tesztkonfiguráció dinamikus, ez azt jelenti, hogy az MTC az egyetlen fixen és automatikusan generált komponens, a PTC k teszt közben törölhetők/létrehozhatók. A create kulcsszó (1) egyszeri az alive az akárhányszori PTC létrehozást jelenti. A komponensek hivatkozhatók a következő kulcsszavakkal: self saját maga mtc system var CompReference := CompType_CT.create létrehozáskor (2)connect(A:port, B:port) pedig 2 irányúan köti össze a két komponenst. Itt A és B is referencia. A (2)mapping a systemet köti össze egy adott porttal; általános szabályai szerint lehet saját komponensre (kivéve a system, aki nem mappelhet magára) két komponens között (többszörösen is, de CSAK külön portpárokon) egy portból két különböző komponensre A connect()és map() után a (3)start()indít el egy viselkedést leíró részt, vagy akár PTC t (ami ha alive, akkor többször is indítható) fontos, hogy a komponenstípusoknak mindenképpen egyezniük kell. Leállítani a kill/stopsegítségével lehet. A (4)done addig blokkolja a futtatást, amíg egy adott PTC le nem fut, míg a killed az aliveptc kre vár amíg azok alive k (ezek a runningés alive műveletekkel tesztelhetők). Összefoglalva az MTC k állapotai: Inactive Running Error Stopped Killed Adat templatek A templatek üzenetsablonok gyakorlatilag, a fő kérdés, hogy a küldött/fogadott üzenet megfelel e a templatenek. 42

43 Definiálni a template <típus> <azonosító> <paraméterek> [ modifies <template, ami alapján készül>] := <mezők, típusok, stb > formában lehet. Annak eldöntésére, hogy a küldött/fogadott üzenet megfelel e a templatenek, a matching szolgál. Azaz a következők szerint definiálhatók templatek, amik alapján szűrhetők az üzenetek: meghatározott értékre szűréskor a template is az értéket tartalmazza complement()szűr a felsorolt értékek komplementerére (bármi, kivéve ) tartomány a (1.. infinity) mintájára adható meg tartomány és értékek, a szintaxis: (( A.. Z ), Heyho );? ha bármi lehet ilyet tartalmazó template küldésre nem használható * ha bármi és üres is lehet a pattern segítségével adható meg illeszkedési minta de minek, ha regexp() is használható. korlátozhatunk hosszra is; template charstring tr_lenexp :=? length(3) ifpresent szolgál arra, ha a mező tartalmát csak akkor kell vizsgálni, ha van olyan mező A matching maga a match(<vett/fogadott üzenet>, <template>) Fontos, hogy a template nem érték, ezért csak a match()használata értelmes. Template használható (de nemajánlott) inline módban is, azaz közvetlenül a fogadott üzenet után: portc.recieve(mytype : { field1 = a, field2 =?}); Templaten belül megadhatók paraméterként változók, amik a törzsben felhasználhatók a mezőkhöz. A template hierarchia lényege, hogy lapos, azaz mindenre van külön template, az egyes fajták egyenesen hivatkoznak egymásra, az öröklődések sosem túl mélyek emiatt a teljes template struktúra egy projekten belül sokszor áttekinthetetlen. Kommunikáció A tesztkomponensek között alapvetően aszinkron és szinkron módon lehet kommunikálni. A kommunikáció üzenetekben testesül meg, melyek port port között küldhetők. Aszinkron esetben a <portid>.send(<érték>)nemblokkoló üzenet szolgál a küldésre, ahol a <portid> egy olyan outvagy inoutport, amin az <érték> típusa definiált. A receive 43

44 ugyanez fordítva, csak itt a bejövő üzenet már blokkoló. Fontos, hogy az üzeneteket sorrendhelyesen kell küldeni, vagyis a: MSG.send( A ); MSG.send( B ); MSG.receive( B ); Hibát fog jelezni, mivel nem B jött először, az csak A után kell érkezzen. A checksegítségével megnézhető (az üzenetet érintetlenül a sor tetején hagyva), hogy adott üzenet megjött e már, a triggerpedig egészen addig blokkol, amíg az adott üzenet meg nem jön További kiegészítés a Value/Sender redirect, ami a következő szintaxisban menti az üzenetek értékét és küldőjét: PortCreceive(MsgTemplate) > value Msg PortCreceive(MsgTemplate) > value Sender A send toés receive frompedig konkrét irányokra (címzettekre/küldőkre) szűr. Viselkedés leírása A soros végrehajtás miatt adódhat holtpont és hasonló jellegű probléma pl. kér blokkoló receive miatt, ha mindkettő egymás után vár üzenetekre, de azok pont fordított sorrendben érkeznek. Erre megoldás az alt { } blokk, amiben a felsorolt utasítások közül az fog futni ami elsőnek bejött. Azaz fel van sorolva egy csomó utasítás (ami bekövetkezhet, ami nem következhet be, hibakezelés, stb ), melyek külön végrehajtási ágak. Az alt hoz érve készül a rendszerről egy pillanatkép (snapshot), azaz minden blokkolódik ilyenkor végignéz minden ágat és amelyik bekövetkezett az hajtódik végre: alt { [] p.receive(resp) { /* ami történik, ha resp jön */ } [] p.receive(keep_alive) { /* ami történik, ha keep_alive jön */ } [else] { /* ami történik, ha a fentiek egyike se következett be */ } } Az altstep { } az alternatíva ágakat terjeszti ki fügvényekké. Könnyebbé teszi a periodikus / hibás üzenetek kezelését. default ként definiálva alapesetben minden alt { } ág helyén meghívódik. Használható még többféle default érték az altstep ből hivatkozhatóan, ezeknél viszont már számít a sorrend (hasonlóan a C/C++ switch vezérléshez). 44

45 A GSM HÁLÓZATI ARCITEKTÚRA (Könyv 12.) Elemek és magyarázatuk röviden, mivel más tárgyak ezek bővebb magyarázatát már lefedték: MS Mobile Station ME Mobile Equipment SIM Subscriber Identification Module NSS Network & Switching Subsystem MSC Mobile Switching Centre VLR Visiting Location Register HLR Home Location Register Itt tárolt az IMSI + MSISDN + a Subscriber Profile (mikre fizetett elő) Auc Authentication Centre EIR Equipment Identity Register {black, grey, whitelist, teszthívások} GMSC Gateway MSC PLMN Public Land Mobile Network egyben BSS + NSS SMSC Short Message Service Centre TRAU Transmission Rate Adapter Unit az A interfészen BSS Base Station Subsystem Base Station Controller Base Transciever Station 45

46 Használt protokollok PLMN en belülre: MTP hívásfelépítés SCCP TCAP MAP/IMAP ISUP hívásfelépítés BSSAP Base Station Subsystem Application Part, SCCP t használ, 2 db értéke van: 0 esetén: Centre BTS vezérlés kapcsolat nélküli SCCP vel 1 esetén előfizetői adatokat továbbít BTS & MSC ifc között DTAP (Direct Transfer App Part) kapcsolatorientált SCCP vel. Call Control, DSS1 alerting Mobility Management Radio Resource mgmt. BTS ME LAPD ME BSS jelzésprotokoll Mobilhálózatoban használt azonosítók: Alapvetően kétféle van: állandó és temporális jellegű azonosító: IMSI International Mobile Subscriber Identity a SIM azonosítója, áll: MCC Mobile Country Code (HU = 216) MNC Mobile Network Code (hálózat azonosítója Pannon 01; Westel 30, Voda 70) MSIN Mobile Subscriber Number MSISDN Mobile Station ISDN Number a közismert telefonszám CC Country Code (+36) NDC National Destination Code (20/30/70) Subscriber Number IMEI International Mobile Equipment ID, készülékazonosító gyártó + típus + sorozatszám (TAC + FAC + SN) 46

47 TMSI Temporary Mobile Subscriber ID user confidentiality, lehallgatás és beszélgetőpartner kitalálása ellen első login: random második login: a random TMSI vel új TMSI t kér LAI Location Area ID, körzetazonosító paginget segíti. MCC Mobile Country Code MNC Mobile Network Code LAC Location Area Code GCI Global Cell Identity, körzeten belüli cellaazonosításra LAI CI Cell Identity MSRN Mobile Station Roaming Number (ennek semmi köze a roaminghoz!) Az MSISDN csak a GMSC ig érvénye, ezután ez használt lásd SCCP, nemzetközi hívás A díjszabásokról 47

48 Titkosítás és Authentikáció PIN kód alapján. Analógia: minden usernél van 1 könyv a központ pedig csak annyit küld, hogy mi az X. oldal Y. karaktere? nem feltörhető. Valóság: A3 és A5 olyan algoritmusok, melyekkel Ki ből és RAND ból SRES és Kc könnyen számítható, de a lefülelt RAND és SRES alapján Kc és Ki valós időben alig kiszámítható. Ennek a hibája, hogy a túl nagy forgalmat generál az AuC felé az MSC is besegít ebben: 48

49 Amikor egy ME kapcsolódik akkor a SIM hez egyedileg rögzített Ki és egy kapott, szintén 128 bites RAND segítségével (amit az ötszörösen kiküldött authorizációs tripletben kapott) kiszámol: SRES Az Auc a HLR segítségével szintén kiszámítja a Ki és RAND ból. Ha a számított és az ME től kapott egyezik, akkor kapcsolódhat. Ciphering Key (Kc) 64 bit, eszerint lesz titkosítva a beszélgetés Lokalizálás A fejezet arról szól, hogy hogyan lehet megtalálni egy mobilt a hálózatban. A hálózat cellákra osztott, de a cellaszintű nyilvántartás túl nagy forgalmat eredményezne, ezért több cellát összefogó Location Area kban nyilvántartottak az elérések; így a paging gyors és a forgalom is kisebb. Szükséges a készülék bekapcsolásakor (IMSI Attach) és kikapcsolásakor (IMSI Detach), valamint periodikusan (lsd. fejezet vége). A központok közül a HLR MSC szinten, a VLR LAI szinten tudja hol vannak az egyes eszközök. A cellaváltás ezen belül történik, az ME dönt róla. Figyeli a közös vezérlőcsatornát, amiből megtudja a GCI t (annak részeként a LAI t is) és a szomszéd cellákban használt frekvenciákat. Emellett folyamatosan figyeli a jelerősségeket is ha egy szomszédos cella jele erősebb akkor azt kezdi el hallgatni (lsd. handover később). 49

50 intra MSC LAI váltás semmi gond; VLR ben átíródik inter MSC LAI váltás Location Update: az új MSC meg kell tudja az: IMSI t kell egy authorizációs triplet felhasználói profil (MSISDN + services) a HLR várja az új MSC azonosítót a régi MSC t értesíteni kell, hogy a VLR ből törölheti a usert. Hálózatok közti jelzésküldéshez a saját HLR nek kell infót küldeni, hogy jelezze hol van és adjon roaming számot HLR a globális címet tudja. Ha az új & régi ugyanahhoz a szolgáltatóhoz (PLMN hez) tartozik, akkor SEND IDENTIFICATION nel lekérhetik egymástól az új MSC IMSI t a TMSI ből. 50

51 A Location update hibavédelme: Tegyük fel, hogy lehal a HLR. Mire helyreáll a helybejegyzések biztos nem aktuálisak már Ezért az eszközök periodikusan, ~3 4 óránként bejelentkeznek a hálózatba, de ezeket a kéréseketmindig elis dobják, kivéve ha baj volt a HLR rel. Recoverynél küld azoknak a KP knak, akikkel kapcsolatban állt, hogy FW olják a periodikus LU kat. Hívások 1. Send Routing Info: MSISDN hez MSRN t kér 2. Provide Roaming Number: IMSI alapján kér MSRN t 3. MSRN visszaküldése 4. MSRN visszaküldése innentől kezdve a GMSC MSRN alapján felépíti a beszédcsatornát (IAM, ISUP ) A keresett MSC onnan tudja, hogy kit kell pagingelni, hogy eredetileg ő küldte vissza az MSRN t (3.) ekkor felírta azt a VLR be is. Ez külföldi hálózat esetén is ugyanígy néz ki. Azonos hálózaton belül is nagyon hasonló, két lehetőség van: Az MSC a hozzá érkező kérést a GMSC hez irányítja, aki az előbbi procedúrát hajtja végre. Előny: a HLR lekérdező funkciót nem kell minden KP nak ismernie Hátrány: fölös forgalom a GMSC felé Minden központ képes HLR t lekérdezni, ekkor az MSC közvetlenül fordul a HLR hez. 51

52 ma ez az elterjedt. Optimalizált routing Két szolgáltató közti megállapodás / beállítás kérdése, lehetővé teszi a másik HLR direkt lekérdezését (kanári MSC a magyar HLR t). Handover Handover (UK), Handoff (US). Jelentése hívásátadás, beszéd közbeni cellaváltás. Fajtái: 52

53 1. Intra BSS adott cellák jelerősségei alapján dönt engedélyezett ha a cella nincs tele. 2. Inter MSC sima VLR beli módsítás 3. Inter MSC egy Anchor Relay szolgál ki végig ami HandOver Number alapján azonosít, a hívás továbbra is ezen keresztül megy. Konkrétabban: Mobile Originated Call CL3I Comlpete Layer 3 Info: tényleges kapcsolatfelépítési üzenet + cellaazonosító GCI. Mobile Terminated Call A * ot követően ugyanúgy az Auth, CpiherMode sorozat játszódik le csak a call proceeding helyett call confirmed van. 53

54 Short Message Service A világ legnagyobb haszonkulccsal dolgozó üzenetküldése. Sima jelzésszolgáltatás, non garantial nincs direkt kapcsolat feladó és címzett között. Működik broadcast verzióban is. Küldése az SMSC n keresztül megy, A küld B nek SMS t. Ez tovább B MSC je felé, ahonnan az MS hez is eljut: Kikapcsolt esetben a központ onnan tudja, hogy SMS t kapott, hogy a készülék bekapcsoláskor Ready For SMS üzenetet küld, ami után tudja küldeni a neki szóló jelzést. Ha ez mégse sikerült, vagy újra kikapcsolták, vagy szolgáltatót váltott. 54

55 Jelzéskapcsolat bontása CSOMAGKAPCSOLT ÁTVITEL A beszédforgalom (CS Circuit Switched) és az adatforgalom (PS Packet Switched) átvitel között a két forgalom jellege miatt is különbségek vannak: A beszédforgalom rövid ideig tart és folytonos, az adatforgalom sokkal tovább tarthat, burstös, hosszabb megszakításokkal, vagyis sokkal több paginget is igényel. Kiegészítése egy meglévő és működő hálózatnak, az első a GPRS (General Packet Radio Service) volt. Ehhez a GSM hálózatot a következőképp kellett kiegészíteni: 55

56 SGSN Serving GPRS Support Node (~MSC) beépített irányítás VLR szerű funkció GGSN Gateway GPRS Support Node (~GMSC) kiút a PDN Packet Data Network felé BG Border Gateway Olyan GGSN, ami másik mobilhálózat felé irányít CG Charging Gateway $$$ PCU Packet Control Unit Továbbá: A HLR már az adatforgalom jellemzőit is kell tárolja: ki mire fizet elő fix IP (ha van) aktuális kiszolgáló SGSN (+az IP je) csatlakozott GGSN A HLR és GGSN, valamint a HLR és SGSN közé kell 1 1 új interfész (Gr, Gc) A Gs interfész összeköti az MSC t és az SGSN t, lényegében azt teszi lehetővé, hogy elég legyen csak az egyik (PS/CS) hálózathoz csatlakozni. A hálózati infrastruktúra kiépítettsége osztályozható: I. kiépített Gs interfész; a mobilok csak az SGSN felé jelentkeznek be II. nincs Gs interfész, 1 csatorna van, de külön külön be kell jelentkezni III. 2 külön csatorna van. 56

57 GPRS képes eszközök Ha egy eszköz csatlakozik a hálózathoz, az a GPRS Attach, ha bont az a GPRS Detach. A készülékeket osztályokba sorolják: Class A: teljesen párhuzamosan tud kezelni adatot és beszédet adat&beszéd paging lehet 2 különálló csatorna Class B: Szimultán Pagingfigyelés lehetséges, de ha az egyikfajta kapcsolat fennáll, akkor a másik nem hozható létre. Class C: Nincs szimultán paging se. Pagingcsökkentés A sok paging (amit az adatforgalom idéz elő) terheli a hálózatot, ezt kell csökkenteni. Módszerek: Routing Area Valódi részhalmaza egy LA nak Adatpaging csak ide jön váltás esetén a RA váltást kell jelezni ebből is sok lesz. az új SGSN gyűjti az adatokat, szól a HLR nek régi SGSN nek null RA körzet ahol nincs GPRS A hálózat nyilvántartja a mobil állapotát adatszempontból: Idle nem kapcsolódik (csak LA szinten azonosít ilyenkor) Ready RA alapján tudjuk melyik cellában van adatforgalmaz, cellát vált stb nem is kell külön paging, hiszen az befér az adatcsomagok közé Standby épp nem forgalmaz, csak az RA váltásokat jelzi 57

58 Azonosítás RAI Routing Area Identifier = LAI + RA Code egyes RA k címzése P_TMSI Packet TMSI, hogy ne a telszám / IMSI menjen adat esetén az 11 kezedtű TMSI k ezek. NSAPI Network Service Access Point ID kapcsolatazonosító a ME részéről kiosztva kell, mert szimultán több adatkapcsolata is lehet a mobilnak, ezeket meg kell egymástól különböztetni PDP Context adatkapcsolatot jelent, újfajta kapcsolat létrehozására külön azonosító GPRS hálózat elérése Access Point Name alapján, ami GGSN t azonosít, amin keresztül az adott típusú hálózat elérhető: network id.operator id ~URL szerű, a kilépési pontokat is megkülönbözteti: internet.mnc030.mcl216.gprs ez tárolódik a HLR ben is A hálózatban virtuális útvonal épül ki, amit később hivatkozni kell tudni, erre jó a GTP GPRS Tunneling Protocol, amivel PATH ok definiálhatók: 58

59 Ha egy PATH egyszer kiépül, akkor végig amíg él a kapcsolat érvényes lesz. Ha egy PATH egyszer kiéül, akkor kiépülhet rajta tunnel is, amit az IMSI + NSAPI azonosít. A tunnel sorrendhelyes beérkezést biztosít a csomagoknak, egyszerre 4 db flow t (adat+vezérlő csatorna) foglal magába. GPRS kapcsolatok felépítése Ha a MS kezdeményez: 59

60 SGSN és GGSN között kell alagút, az NSAPI ezt fogja azonosítani. MS ben végződtetett kapcsolat Ehhez kell a fix IP jű előfizető címe, akinél az adatkapcsolat végződik: 60

61 SZÁMHORDOZÁS Feltétel nélküli hívásátirányítás, továbbirányítás, onboard routing. A szolgáltatók számblokkokat vesznek (így ők számblokkok eredeti tulajdonosai), az ezekhez rendelt egyes számok kerülnek át más szolgáltatókhoz, akik eszerint lehetnek: átadó / donor befogadó / átvevő tranzit További alapfogalmak: Kezdeményező KP az, akit hívnak Szolgáltató alatt a számblokk szolgáltatót kell érteni 61

62 Megvalósítások Szolgáltató tud mindent Hívás, visszahívás Drop back Az EU ban nem lehet így, mert a szolgáltató nem tudhatja a számot Indirekt irányítás 62

63 Lekérdezés minden hívásnál (ha nagyon sok a hordozott szám) Minden szolgáltatónál kell lennie egy üzemi adatbázisnak. Globálisan van egy Központi Referencia Adatbázis, ahova minden hordozást be kell jelenteni. (ez Magyarországon állami, az NMHH tartja karban), az üzemi adatbázisokat ehhez szinkronizálják. RN: Routing Number ideiglenes szám amin megtalálhatjuk a hordozottat, ezt csak a szolgáltató tárolja, 2x3 jegyű: (Berendezés + Szolgáltató Kód) Mobilhálózatokban + Intelligens hálózatoknál SRF Signalling Relay Function: SMS és egyéb központokhoz rendelt eszköz, amin minden jelzés átmegy: 63

64 Színes hívások 64

65 ZH feladatok LAPD javítási módszer A LAPD keretekben több lehetőség is van a hibajavításra, illetve detektálásra: A Vezérlés részben I és S keretek esetén feltüntetett a vételi / adási sorszám Az utolsó előtti két octetben pedig ellenőrző összeg. Rossz sorszám esetén kérhető újra az üzenet, hibás ellenőrző összeg esetén paritásbitek alapján megkísérelhető a javítás, de jó eséllyel eldobódik a keret... A B SABME > < UA N(S)=0 N(R)=0 > // kiindulás: senki nem küldött semmit < N(S)=0 N(R)=1 N(S)=1 N(R)=1 > < RR N(R)=2 N(S)=2 N(R)=1 > < RR N(R)=3 N(S)=3 N(R)=1! > //1 bit hiba > a keret eldobódik N(S)=4 N(R)=1 > //de még a 3 nem jött meg... < REJ N(R)=3 //3 mat küldd újra! N(S)=3 N(R)=1 > < N(S)=1 N(R)=4 N(S)=4 N(R)=2 > //nyugtázott keretek sorszáma növelhető < DISC UA > U keret I keret S keret Összegezve: az N(S) és N(R) segítségével nyomon követhető, hogy milyen üzenetek érkeztek, ha kimaradt valami a vett jelek sorából akkor, REJ kerettel kérhető az ismétlés. MTP2 javítási módszer Basic Error Correction ha 8000 km nél kevesebb a táv Preventive Cyclic Retransmission ha több, mint 8000 km a módszer hasonló, csak akkor küldi fel ha az összes megjött ( műholdas esetben pl.) BSN: Backward Sequence Number utoljára helyesen vett üzenet sorszáma (0..127) 65

66 FSN: Forward Sequence Number küldött üzenet sorszáma (0..127) BIB: Backward Indicator Bit ha invertálódik hiba történt FIB: Forward Indicator Bit ha invertálódik korábban elküldött üzenet megy újra Pl. a következő fullduplex kommunikáció. A küld, B fogad. Az áttekinthetőség kedvéért a B A irányú visszaigazolásokat nem tüntettem fel, de azok 2 ütemmel később visszaérnek (pl. a 7 re akkor ér vissza, amikor A már a 9 et küldené ) LAPD TEI menedzselési eljárás (Automatikus) UI kereteket használ, SAPI = 63 és TEI = 127 (broadcast) Hozzárendelés: Mindig a terminál kezdeményezi: 16 bites Random Number kiadott TEI, vagy denied ha nincs szabad TEI, akkor ellenőriz minden TEI t 2x, hogy foglalt e. ha nem kap választ egyik kérésre sem, akkor nem is foglalt Ellenőrzés: 66

67 Hálózat kezdeményezi: Check Request (vagy minden TEI t ellenőrünk, vagy csak egy bizonyosat) minden terminál beküldi az általa használt TEI t (amik nem jönnek vissza 2x sem, azokat szabadnak tekinti) Visszavétel: Hálózat kezdeményezi: Reference Number = 0; akkor történik, ha 2x nincs válasz, vagy nem használták egy ideje Összetett TCAP tranzakció (részletesen, azonosítókkal, üzenet és komponenstípusok) Összetett, azaz több üzenetváltásból áll a tranzakció; a válasz continue üzenetekből áll, a folytatott küldés is continue. Continue azonosítók jelentése: OTID az az üzenet, ami a DTID számon nyilvántartott üzenethez tartozik OTID saját generált szám, amin a küldő nyilvántartja a tranzakciót, a DTID erre lesz majd válasz A komponensek kékkel és dőlten szedettek. Az első mindig Invoke, adott ID vel. Itt egy összetett műveletből áll a tranzakció ( Return Result Not Last). Egyszerű műveletek esetén új Invoke ID kkel indulma mindig a következő művelet. Hiba esetén: ha a protokoll értelmezhetetlen: Reject ha a művelet a hibás, akkor Return Error következik. 67

68 Nemzetközi hívás felépítése (nemzeti és nemzetközi jelzéspontok, kódok hozzárendelése, felépült jelzéskapcsolatok, OPC, DPC értékek) Az egyes nemzeti szolgáltatóknak kell legyen nemzetközi központja (GSP), aminek van globális jelzéshálózatbeli jezéspontkódja és hazai hálózatbeli jezéspontkódja is. Alice hívja Bobot: [] ben a jelzéspontkódok szerepelnek 1. Alice szolgáltatója (WonderFon) fogadja Bob számát 2. A WonderFon SP je [123] detektálja, hogy ez külföldi szám és egy IAM üzenetben továbbítja a A WonderFon GSP felé a WonderFon hálózatán belül [12], ehhez lefoglal egy beszédáramkört 3. A WonderFon GSP eldönti, hogy melyik nemzetközi jelzéshálózatbeli GSP felé kell továbbítani a hívást [1 01], ha megvan elküld az a megfelelő TeleBob GSP felé egy IAM üzenetet a nemzetközi hálózaton [1 03]. 4. A TeleBob GSP je továbbítja a híváskezdeményezést a TeleBob hívásvezérlő egységnek [32]. 5. A TeleBob hálózatában a GSP [32] küld egy IAM üzenetet ahhoz az SP hez, amiről Bob értesíthető [323] 6. Ezek után erre a hívásra minden jelzés pontosan ezen a csatornán fog haladni. IAM üzenetek: IAM #1: OPC = 123; DPC = 12; NI = WONDERFON IAM #2: OPC = 1 01; DPC = 1 03; NI = INTERNATIONAL IAM #3: OPC = 32; DPC = 323; NI = TELEBOB 68

69 SCCP globális címfordítási képessége Alapprobléma: MTP által használt jelzéspontkódok csak egy hálózaton belül működnek. Az SCCP képes a globális címet (többnyire MSISDN) értelmezni: Az SCCP emellett képes különbséget tenni a funkcionális egységek között címmezőben lévő kód alapján. Az UDT üzenetek ha A beli előfizető hív egy B belit és A és B más országban van. A SP A GSP A GSP B GSP B GSP B SP DPC = A SP DPC = A GSP DPC = B GSP OPC = A GSP OPC = B GSP OPC = B SP NI = A hálózat NI = nemzetközi NI = B hálózat GT = MSISDN GT = MSISDN GT = MSISDN Az OPC és a DPC úgy változik, mint eddig, csak az útvonal meghatározása megy a GT segítségével. Nyílt számozási rendszer összehasonlítása a zárt számozási rendszerrel Nyílt számozási rendszer a számoknak nem csak egy alakja van, belföldi rendeltetési szám körzeten belül is változó lehet körzeten belül elég csak az előfizetői számot hívni körzeten kívülről viszont előtétszámot és körzetszámot is tárcsázni kell. kevesebb számjegyet kell bepötyögni nem mindig egyértelmű a hosszú és rövid alak megkülönböztetésére használt előtét miatt a teljes szám tárcsázásakor Zárt számozási rendszer a számoknak csak egy alakja van, belföldi rendeltetési szám hossza országosan fix benne van a belföldi rendeltetési szám is. a tárcsázási folyamat hosszabb egyszerűbb a központ több számot lehet kiosztani az előfizetőknek ASN.1 leírás & TCAP típusok ASN.1 BER szerint kódolhatók a TCAP üzenetei, az OPERATION és ERROR makró segítségével. 69

70 művelet OPERATION ARGUMENT kérdésparaméterek RESULT opcionális válaszparaméterek ERRORS opcionális { hibanévlista } ::= localvalue műveletkód Gyakorlatban a checkimei megnézni lopott e a telóm. A kódja 2BH = 43. Lekérdezéshez elküldi az IMEI t (ami 3..8 octet hosszú string), vár egy enum elemet (lopott, enyém, szürke). Azaz: checkimei OPERATION ARGUMENT imei OCTET STRING (SIZE (3..8)) RESULT equipmentstatus ENUMERATED { whitelisted (0), blacklisted (1), greylisted (2) } ERROR { hibák } ::== localvalue 43 EU/US PCM struktúra ismertetése EU Unrestricted 32 csatorna / frame, adat v. beszéd Sub multiframe: 8 keret; ami az alapvető védelmi egység is. CRC képes kód: 8 keret 4 bit CRC vonalminőség jobb. Sebesség Mbps = 32*62 kbps. US Restricted 24 csatorna / frame, csak beszéd. Multi frame nként 12 frame fér el ( 1.5 ms). Overhead kicsi. Sebesség Mbps = 24*56 kbps. 70

71 Minta jelzéshálózat átkonfigurálódása adott meghibásodások esetén Adott a mintahálózat ami két tetszőleges jelzéspont között elérhető. Meghibásodás esetén a hibát észlelő pont továbbítja a letiltást jelző üzeneteket a szomszédos jelzéspontok felé. Letiltás nem csak hiba esetén fordul elő, hanem: Ha egy kibás pont megjavul, akkor a szomszédai ismét elküldik a tiltást (azaz azoknak a pontoknak a listáját, amik nem elérhetők), ezzel tudatva, hogy már elérhető. Ha olyan üzenetet kap, aminek a címzettje felőle elérhetetlen, akkor visszaküldi a feladó felé a tiltást. Jelen esetben Alice és Bob nem személyek, hanem Signalling Pointok. Először a Pr1 fut, ha kiesik egy link, életbe lép egy Pr2-es, ha ez után is kiesik és már nincs használható Pr2-es, akkor kell egy Pr3-as. Két különböző központban lévő ISDN készülék közti hívásfelépítés A kék üzenetek LAPD I keretek; a zöld üzenetek az U keretek. Ezeken belül emlékeztetőül a Set Asynchronous Balanced Mode Extended - aszinkron mód beállítása; Unnumbered Acknowledgement - sorszámozatlan nyugta. Az ISUP üzenetek jelentése: Initial Address Message, Subsequent Address Message, Address Complete Message, Call ProGress, ANswer Message. 71

72 Teszttípusok bemutatása Conformance - Belső működésbe nem belenézve vizsgáljuk a kimeneteket, nem állítja, hogy 100%-ban megfelel -e a specifikációnak, hanem csak felületesebben, hogy vannak -e jó beállítások + statikus & dinamikus tulajdpnságok ellenőrzése. Interoperability - Mennyire képes együttműködni a környezetével a protokoll a környezetével / más eszközökkel Performance - mekkora forgalmat bír, mik a késleltetések, stb... Mélység szerint: [felületes] Basic Interconnection Capability Behaviour Conformance Resolution Test [alapos] 72

73 Protokolltesztelés leírása, milyen dokumentációk szükségesek? 1. Specifikáció (szöveges) alapján meghatározzuk a tesztcélokat, ami alapján az ATS elkészül. 2. A PIXIT és a PICS (formális) az alkalmassági nyilatkozat és az extra információk, amik alapján eldönthető, hogy milyen funkciókat, tulajdonságokat fog kelleni ellenőrizni. 3. Az előző két pont információit felhasználva a labor elkészíti az ATS ből az ETS t. 4. A futása során előáll a Test Log, futás után a Conformance Test Reportok (=tesztbizonyítványok) 73

74 TCAP összetett tranzakcióra mutasson egy példát. Hogy tudunk hibát javítani? Hibajavítás, attól függ milyen hiba. A TCAP SCCP felett megy, az SCCP pedig MTP felett. MTP szinten a BIB / FIB invertálódik ha urgrás (azaz hiba) volt a küldött FSN ben (lásd MTP2 javítás). SCCP szinten kapcsolatorientált kommunikáció jöhet csak szóba ha ennek felépítésekor van hiba, akkor Connection REFusal üzenetben bont a fogadó, vagy rendes bontáskor küldi a bontás (adott esetben hiba) okát is. TCAP szinten ha valami fatális hiba történik, amia végrehajtást/felismerést lehetetlenné teszi, akkor ENDhelyett ABORTüzenettel zárul, ami tartalmazza a hiba helyét és okát is. A fenti három módszer rámutat a hibára, amit ezután a küldő ki tud javítani. Teszttípusok Tesztelési szempontok: Conformance (specifikációnak megfelel?) Interoperability (környezettek együttműködik?) Performance (terhelést bírja?) Teszt mélysége: Basic Interconnection (alap) Capability (képességek) Behaviour (viselkedés) Conformance Resolution (kiterjesztett vizsgálat) Teszt elredezése alapján Lokális Elosztott Koordinált Távoli 74

75 SCCP mikor és hogyan javít, egy példán keresztül Két lehetőség van: Kapcsolat nélkül: Értelmezhetetlen SCCP UDT üzenet érkezik. A hiba okával együtt az értelmezhetetlen üzenet bekerül egy UniDaTaService üzenetbe Visszaküldi Kapcsolatorientált A kapcsolat vagy fel sem épül (CREF) vagy az RLSD üzenet tartalmazza a bontás okát. Javíthatnak még az alsóbb/felsőbb rétegek is, MTP 2 vagy TCAP szinten pl. Vizsgafeladatok Tesztkomponensek felrajzolása, tesztesemény kimenetele, folyamata TTCNv3 kód alapján 75

76 Feladat az ábra alapján: egyszerű kérés válasz protokol, max 5 s válaszidő, a siker pass, különben fail. type port PT message { out A, B, C; in X, Y, Z; } type component CT { timer T := 5.0; port PT P; } testcase test1() runs on CT { var default d := activate(as()); map(mtc:p, system:p); p.send(a); T.start(); p.receive(x); p.send(b); T.start(); p.receive(y); p.send(c); T.start(); p.receive(z); } deactivate(d); setverdict(pass); altstep as() runs on CT { [] P.receive {setverdict(fail)} [] T.timeout {setverdict(inconc)} } ASN.1 leírásban bemutatott MAP üzenet kódolása, küldhető TCAP típusok Egyszerű és összetett TCAP is kódolható, ha vannak válaszok akkor azt a RESULT és ERRORS mezőkben lehet opcionálisan megadni. Konkrét példa a CheckIMEI MAP üzenet: Adott IMEI melyik listán van (white,gray,black)? 76

77 Lekérdezéskor az ARGUMENT utáni paraméter használt, a RESULT a válasz, hiba esetén az ERROR jön: checkimei OPERATION ARGUMENT imei OCTET STRING (SIZE (3..8)) RESULT equipmentstatus ENUMERATED { whitelisted (0), blacklisted (1), greylisted (2)} ERRORS { systemfailure, datamissing, unexpecteddatavalue, unknownequipment } ::= localvalue 43 A kódolás ebben a formában nem lehetséges (ez a séma); az ebből kreált üzenetek: checkimei OPERATION ::= { imei OCTET STRING (SIZE (3..8)) } value = 888 checkimei OPERATION ::= { equipmentstatus ENUMERATED {whitelisted (0),blackListed (1),greyListed (2) } value = 1 ERROR... GSM location update NSS ben Új MSC alá kerül a ME, PLMN t nem vált: 77

78 Ha lenne PLMN váltás, a HLR nek kellene az AuthInfot küldeni, + ilyenkor az ME től az IMSI t is muszáj bekérni. A HLR értesíti egyben a régi MSC t is Interfészek: MAP/D: HLR VLR kommunikáció (VLR HLR) hol a mobil? (HLR VLR) ME service ifc. MAP/G: VLR (új & régi) váltás ifc Authorizáció: ME login nál megadja a régi LAI t ismert ki volt az előző MSC/VLR, tőle elkérhető az Auth. Triplet. Mikor kell a GPRS esetén a paginget csökkenteni Az adatforgalom szemben a beszédforgalommal sokáig tart, burstös, több cellaváltás is végbemehet egy kapcsolat során, ami sok készülékre sok paginget jelent. Lehetőleg el kell kerülni, hogy egy teljes LA ra terjedjen ki a paging, valamint azt, hogy folyamatosan kelljen. SMS útja a feladótól(a) a központig(b) 78

79 Interfészek: MAP/E: Inter MSC kommunikáció, Handover & SMS célok MAP/C (G)MSC & HLR MSRN lekérdezéshez Ha ki lenne kapcsolva a fogadó mobil, akkor: Az SMSC(A) visszakapna egy StatusReportot a HLR től Amint B bekapcsol, szól a HLR nek, hogy I m Ready for SMS Ez után a HLR elküldi neki a tárolt SMS t. GSM legfontosabb azonosítói IMSI Mobile Country Code HU) Mobile Network Code (01/30/70) Mobile Subscriber ID Number 79