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

Protokolltechnológia (BMEVITMA364) nemhivatalos minimáljegyzet v1 2014. 04. 20 2014. 06. 05.

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 23. 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

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 PLMNen 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 GPRSké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

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 NSSben 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 [email protected] címen!

HANGÁTVITEL A 3003400 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

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 Pingpong TDM esetén max 1.5 km a 125 μs miatt, FDM esetén ugyanez 810 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 μsonké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

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 USAban a μlaw az EUban az Alaw szerint specifikált. A döntési szint környékén kis amplitúdóval váltakozó jel (midriser) é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: ++++ |*|07|815| → előjel | szegmenskijelölés | intervallumkijelölés ++++ Vonali kódolás lehetséges jelátmenettel (Non Return to Zero önszinkronizáló és DCkomponens 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 Pulse Code Modulation egy frameje pontosan 125 μsig tart és így néz ki: 5

+++++ |D| B |D| B | = 125 μs +++++ 0 1 .. 15 16 .. 31 Az első D mindig az előre definiált SYN kódszó [X0011011], 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). Multiframe az, amikor 16 frame áll össze, 2 msig tart. A multiframen belüli framek 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 117, 218, …, i, 16+i, … 15, 31. *A *B ++++++ ++ |SYN| B |1&17| B |SRV| B SYN… B |3&19| ++++++ ++ 0 16 0 16

Ha a 17. beszélgetés az *A pontban ér véget, akkor az még ebben a multiframeben érvényre jut. Ha a *B pontban ér véget, akkor már meg kell várni a következő multiframet.

PCM SZABVÁNYOK EU “Unrestricted” CRC képes kód: 8 keret → 4 bit CRC ⇒ vonalminőség jobb. Submultiframe: 8 keret; ami az alapvető védelmi egység is. Sebesség 2.048 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. framekben. Multiframenként 12 frame fér el (⇒1.5 ms). Multiframe esetén a SYN kódszó keretenként a legelső bitekben van. Overhead kicsi. Sebesség 1.544 Mbps = 24*56 kbps.

ANALÓG ELŐFIZETŐI HÁLÓZAT JELZÉSEI Polling alapú előfizetőinfó detektálás: offhook esetén zár az áramkör és indul a folyamat:

6

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 msnyi szakadás, köztük egyenként 33 ms szünettel jelent egy számjegyet. Dual Tone MultiFrequency hangjelet állít elő 4 + 4 különböző szinuszjelből 11et kiválaztva és azokat összegezve. sin()

1209 Hz

1336 Hz

1477 Hz 1633 Hz

697 Hz

1

2

3

A

770 Hz

4

5

6

B

852 Hz

7

8

9

C

941 Hz

*

0

#

D

5 ⇒ 1336 Hz + 770 Hz = 2106 Hz 7

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, (0val, vagy 1gyel nem kezdődhet szám), timer méri, hogy végee 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 (inband: DC komponenses, DTMF) / Sávon kívüli (offband: 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

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 quasiassociated 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ásmás útvonalon). A vízszintes / ferde folytonos összeköttetések (Pr1) (2 párhuzamos útvonal van a végpontok között!) 5050%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

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 (ISDND 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 1es után kötelező 0t beszúrni, különben tévesen véget érhet a keret. ++ | 01111110 | 1. 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| N2. octet | (sum) | N1. octet ++ | 01111110 | 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ó. 0..63 fix készülékeknek; 64..126 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

○ 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) RNnel indul, broadcastol ● Ha teljesíthető → assigned: ha nem; ellenőrzi biztos nincse szabad TEI. ○ check eljárás indul, amit a hálózat kezdeményez, ahol RN=0. Konkrét TEIre kérdez rá, aminek a birtokosa válaszol. ■ Ha a válaszokban van 2 azonos RN, vagy TEI → elveszi a TEIt (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 IEket 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

● 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

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 SCCPISUP 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 ISUPnak 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 SS7es üzenet, a rétegek feltüntetésével. Itt egy sima (nem SCCP feletti) ISUP üzenet megy át. Az MTP3mas 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

Ü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 MTPk azért felelnek, hogy jelzáshálózaton belül Alice és Bob (akik SPk…) 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) ● FillIn Signal Unit (töltelék, kb. az üzenetek 96%a) ++++++++++ | FLAG |CK| info | LI |FIB| FSN |BIB| BSN | FLAG | ++++++++++ 8 16 * 6 1 7 1 7 8 bit ● FLAG mindig 01111110 (itt is van bit stuffing: 5db 1es után 0) ● CK checksum ● info legfeljebb 272 bit, de ez az LIben 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 ○ Outofservice egyéb hiba. ○ Outofalignment túl hosszú üzenet, túl sok 1es egymás után ○ Normal / Emergency alignment 216 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

● 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 kmnél rövidebb szakaszok esetére. Az MSUkat FSNben sorszámozza, BSNnel ellenőrzi, hiba esetén a BIBbel jelez, ahol invertált FIBet 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 MSUt szállító MTP 2jelzé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 zoneIDből ● 8 bit Area Network codeból ● 3 bit országos nemzeti KPjelzőből National Regulatory Authority pl. NMHH → meghatározza a jelzéspontkódokat. 9 biten azonosítja a szolgáltatókat, 5 biten az ISPCt. 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 infoval 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

● 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 SPk címe az NSPC, a GSPknek (mivel két hálózatnak is a részei) van NSPCje és ISPCje 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 (20337). 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ó SPje 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 → SIOban a hálózatindikátor ezt mutatja. ● GSP feldolgozza a beérkezett hívást. ● A GSPn 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 GSPje felé → ennek a SIOja a nemzetközi jelet tartalmazza. 16

● A célország GSPje 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 SPk, GSPk központjai döntenek, a végpontok nem rendelkeznek topológiai ismeretekkel. A kommunikáció során tehát a SIOk hálózatonként, a DPCk, OPCk 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) | endofoptional 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

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égpontvé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 ANMek megvárják egymást: 18

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

Á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

Nemzetközi hívás SCCPvel ● A hívó ország MSCje a hívott készülék hívószámát (MSISDN = 18) véve meghatározza a célországot, majd a SCCPnek (aki a nemzetközi kapu, a GSCCP felé továbbít majd) továbbadja az MSISDNt ● Az üzenet DCPje a GSSCP jelzéspont kódja (=33); a hálózatindikátor nemzeti. ● A hazai GSCCP a hívott MSISDNjé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 GSCCPjének jelzéspont kódja(=2011) (más néven ISPC) ● A célország GSCCPje a kapott MSISDN alapján kinézi a saját országa HLRjéből a hívott jelzéspont kódját (HLR = 10 → MSISDN = 18) ● Ez után a nemzeti hálózaton a HLRen keresztül találja meg a hívott eszközt. Különbség az ISUPtól az, hogy nem szakaszonkénti a hívásfelépítés. Az MTPk 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

egyedül CICkódot nem tartalmaznak. Tranzakciók azonosítását nem támogatja; csak az SS7en 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

● End utolsó üzenet, a fogadó oldal küldi ○ Destination Transaction IDentifier, megegyezik a Beginben kapott OTIDvel. ● 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 ⇒ usecase. 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

● 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 telconak megfelelő legyen egy specifikáció: ● párhuzamos események leírhatósága ● nemdeterminisztikus folyamatok leírása (~forgalom, stb…) ● realtime 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

★ 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 (EFSMek) 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 CEFSMnel, 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ámcsö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

Adatspecifikáció kiegészítő elem a viselkedési és szerkezetleírók mellé. Általánosan leírja, hogy a PDUk, ü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

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

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 PDUkat a közegen (medium) továbbítja, kapcsolatorientált adatátvitellel. Fázisok: ● Kapcsolatfelépítés initiator kezdeményez Connection Request PDUval, 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 AcKkal válaszol. Ha sokáig nem jön ACK, akkor bont. Az adattovábbítás sorszámozott, mindig az ACKolt 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 SDLben 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

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, PDUk 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 0val tölti fel. Főbb beépített típusok: ● INTEGER ● BOOLEAN ● REAL ● BIT_STRING pl. ‘0101’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 subtypeok 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

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 TAGen 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 valueba á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 [1|000000] → 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

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 valuet 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 valueja → pont nem fér ki 5 biten (az 11111 a hosszú formátumra utal már!) ezért 2 TAG kell. A típus összetett is, vagyis indefinit a hossz, a valueban 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 128at. végül komolyan következik 128 db FF octet. A valuet közvetlenül követi két csupa null octet. ● eimplicit bit string 4es é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 valuenak. Végül a value tartalmazza (balról kezdve) a bitmintát. ● f 5ös TAG értékű, egyszerű bool változó, ahol a az érték egy db 1es. ● g5ös TAG értékkel egy 0 értékű hosszoctet. Ezt követi kétszer két csupa null octet, ami a pelda és SET lezárása. Jobban érthető minden egy ábrával. A Piros, narancs, kék és világoskék keretek az összetett valuekat szemléltetik. A d mező kivételével minden mező octetjei egy sorban vannak

31

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

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 Observationon (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

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 IUTben (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 IUTn keresztül küldött üzenetek alapján hozható ítélet. További szempont a PCO elhelyezkedése az SUThez 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

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énysorozatokbó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. 2010es ETSI 4.2.1ben 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

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 from MyModule 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

● 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 deactivate mű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 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

a megfelelő, sorrendet kitöltő számokkal. Az integerek különböző sorrendű hozzárendelése akár teljesen azonos enumokhoz 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. infinity nem 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 TTCNben: ● module globális ● control modul kontroll része, innen kilátni a modul felé ○ block { … } törzs ○ function ○ altstep ○ testcase ○ component Egy TTCN3 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

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 configfileban 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; .starttal 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 IUTvel, hogy valós környezetben van. Az ábrákon dobozok (komponensek) kommunikálnak portokon (interfészek) keresztül:

39

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

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 MTCn 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 builtin verdictek, melyek a setverdict() és getverdicttel 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).

Végső

none

none none

pass

Rész inconc

pass

inconc

fail

error

fail

error

41

pass inconc fail

pass

pass

inconc

fail

error

inconc

inconc

inconc

fail

error

fail

fail

fail

fail

error

Konfigurációs műveletek A TTCN3 tesztkonfiguráció dinamikus, ez azt jelenti, hogy az MTC az egyetlen fixen és automatikusan generált komponens, a PTCk 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 PTCt (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 alivePTCkre vár amíg azok alivek (ezek a runningés alive műveletekkel tesztelhetők). Összefoglalva az MTCk á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

Definiálni a template <paraméterek> [ modifies ] := <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(,

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

Recommend Documents