SZAKDOLGOZAT. Tóth Szabolcs F43L90

SZAKDOLGOZAT Tóth Szabolcs F43L90

Miskolc 2013

Miskolci Egyetem Gépészmérnöki és Informatikai kar

Vezeték nélküli IPTV-s adatfolyamok javítására képes szoftver folytatása és validálása.

Tervezésvezető:

Készítette:

Dr. Kane Amadou

Tóth Szabolcs

Egyetemi docens

mérnök-informatikus hallgató

Miskolc 2013

A vezeték nélküli IPTV-s adatfolyamok javítására képes szoftver folytatása és validálása

Tartalomjegyzék Bevezetés: ........................................................................................................................ 4 1. A digitális televíziózás .................................................................................................. 5 1.1. A digitális televíziózás története ........................................................................... 5 1.2. DVB Projekt ........................................................................................................... 6 1.3. Az IP-alapú műsorszórás ismertetése ................................................................... 9 2. IPTV adatfolyamok bemutatása ................................................................................. 12 2.1. Forráskódolás ...................................................................................................... 12 2.2. Transport Stream ................................................................................................ 16 2.3. Internet Protocol................................................................................................. 19 2.4. További fontosabb protocol-ok .......................................................................... 22 3. Vezeték nélküli átviteli módok ismertetése .............................................................. 25 WiFi ............................................................................................................................ 25 IEEE Szabványok ......................................................................................................... 25 Titkosítások ................................................................................................................ 27 4. Mérések ..................................................................................................................... 29 Méréshez használt eszközök...................................................................................... 29 Mérési helyszínek....................................................................................................... 32 Méréshez használt programok .................................................................................. 33 Mérési konfigurációk ................................................................................................. 34 Mérési eredmények ................................................................................................... 37 5. A vezeték nélküli IPTV-s adatfolyamok javítására képes szoftver folytatása ............ 39 5.1. Java nyelv rövid ismertetése ............................................................................... 39 5.2. Iframer program ismertetése ............................................................................. 40 5.3. A programon végzett fejlesztések ...................................................................... 42 6. Az elkészült szoftver validálása .................................................................................. 51 6.1. Különböző Framek javításának vizsgálata .......................................................... 51 6.2. IFramer programmal mért eredmények ............................................................. 52 Összefoglalás .................................................................................................................. 56 Summary ........................................................................................................................ 57 Irodalomjegyzék ............................................................................................................. 58

3


Bevezetés: A digitális televíziózás rohamos fejlődése következtében ma már több szolgáltatónál lehetőségünk van IPTV alapú televíziózásra, ez részben a szélessávú hálózatok nagyfokú sebesség-növekedésének tudható be. Másik fontos dolog, hogy ma már a legtöbb háztartásban van internet hozzáférhetőség és wifi, amin keresztül akár vezeték nélkül is lehetőségünk van IPTV adás továbbítására. Szakdolgozatom témája egy vezeték nélküli IPTV-s adatfolyam javítására képes szoftver folytatása és annak validálása. Ez a vezeték nélküli hálózatok hibáiból és az IPTV által használt szállítási réteg hibáiból adódó minőségromlás kivédésére használható program. A streamben a képi információk újrakérésével a lejátszás minőségét növeli. Dolgozatom első felében bemutatom a program könnyebb megértéséhez szükséges elméleti háttereket, a digitális televíziózást, valamint az IPTV által nyújtott előnyöket. Ezután betekintést nyújtok az IPTV adatfolyamok felépítésébe, a használt protokollokba, az IPTV-nél használt tömörítő eljárásokba, a teljesség igénye nélkül. Dolgozatomban bemutatom továbbá a vezeték nélküli átviteli módokat. A wifi-t és további szabványait, valamint ezek titkosításait. Majd dolgozatom fő része, az IPTV-s mérések bemutatása és elemzése következik. Itt helyet kap a méréshez használt eszközök felsorolása, valamint a mérési helyszínek bemutatása. Ezután az eddig Porcs Milán Lajos által elkészített IFramer programot mutatom be, a program által használt java nyelv alapfogalmainak ismertetésével. Majd az általam végzett bővítések leírása jön. Dolgozatom végén pedig az elkészült szoftver validálását mutatom be, a iFramer programmal végzett méréseket összehasonlítva a program nélküli mérésekkel, ugyanazon körülmények között.

4


1. A digitális televíziózás Mielőtt még rátérnék az IPTV ismertetésére, kezdjük azzal, hogy megismerkedünk a digitális televíziózás történetével, különböző szabványaival, és hogy mi is az a digitális műsorszórás.

1.1. A digitális televíziózás története A digitális televíziózás kezdete egészen 1968-ig visszanyúlik, amikor már Japánban elkezdték a HDTV-rendszer kifejlesztését segítő kutatásokat, amelyek egy olyan vizsgálatra épültek, amely megtalálta azt a képméretarányt, ami az emberi látáshoz a legjobban illeszkedik, ez a régi 35mm-es film aránya volt, a 16:9-es arány (1. ábra). Ezenkívül még megállapították, hogy az új HDTV-nek felbontásának nagyobbnak kell lennie, mint 1000 sor. Az első kísérletek a digitális műsorszórásra a 70-es évek közepére tehetőek, ahol a képek sorszáma 1125 volt.

1. ábra: SDTV és HDTV különbség

A digitális Televíziózás Európában Európában az European Broadcasting Union avagy EBU indította el a Cine – Vision nevű projekt-tét 1981-ben, melyben HDTV-t tanulmányozták. 1983-ban a CCIR-rel (Comite Consultatif Internatinal des Radiocommunications) megalakítják az IWP ideiglenes munkabizottságot (Interim Working Party). Céljuk egy világszabvány létrehozása. 1985-ben az IWP elfogadta a Nippon Hoso Kyokai azaz a Japán műsorszóró intézet javaslatát a 1125 soros, 60 Hz-es félkép frekvenciáról, azonban Európában az 50 Hz-es hálózat miatt ez nagy ellenállásba ütközött volna. 1985-ben az EC (European Comission) a tagállamokat az IWP javaslata ellen állította. Emiatt ketté is vált USA és Európa HDTV szabványválasztása (1990). A HDTV-s célok eléréséhez egy új projektet indítottak az Eureka95-öt, melynek két célja volt, az egyik a CCIR 1990es ülésén bemutatni a HDTV rendszert, a másik hogy a 5


HDTV képtovábbítás műholdon, a MAC (Multiplex Analogue Components) rendszerre épüljön, úgy hogy a hagyományos MAC vevő a HD-MAC vételét is tudja. Az Eureka 95 időtartama 86-90 közé tehető, amit 1989-ben még 2 évvel meghosszabbítottak, azonban ezután új HDTV rendszerek jelentek melyek jobb tulajdonsággal rendelkeztek a HD-MACnél , így az angol kormány megvonta az Eureka95-től a támogatást. 1990-ben a skandináv országok is dolgoztak ki saját HDTV javaslatot HD-DIVINE néven, majd Németországban is egyre több projektek indultak a televíziósás hova tartása végett. Németország összehívta a telekommunikációs és rádiókommunikációs műsorszórókat, szervezeteket, gyártókat, mert felismerte, hogy fontos lenne a digitális televíziósásnak egy közös európai megközelítése. Ebből alakult ki az European Launching Group, ELG avagy az „Európai Elindító Csoport” 1992-ben. Egy évvel később a telekommunikációs szervezet, a műsorszóró, gyártó és szabályozásért felelős hatóság az egyetértési nyilatkozat (MoU) aláírásával elindították az Európai DVB projektet. Eközben a piackutatás eredményeként rájöttek, hogy a vevők inkább a több csatornát preferálnák, mint a jobb HDTV minőséget. Részben emiatt a DVB projekt inkább a lehető legtöbb és legjobb digitális 16:9-es hagyományos SDTV minőségű adás biztosítását tűzte ki célul. Ezen kívül, a DVB projekt elfogadta az MPEG-2 alapú képés hangkódolást és a multiplexelési elveket. Az EC megadta azokat a direktívákat is, amelyeket Európában a televízió technika szabványosításánál be kell tartani. 1994-ben jelent meg a DVB műholdas (DVB-S) és kábeles (DVB-C) ajánlása, majd 1997-ben a földfelszíni (DVB-T) is, amelyekből mind szabvány lett.

A digitális televíziózás Magyarországon 1999. július 9-én kezdték meg az első hazai kísérleti adást az Antenna Hungáriánál, hogy a Széchenyi-hegyi adóállomáshoz egy digitális műsorszórásra alkalmas adót telepítettek. A Szávai utcai adótoronyba is bekerült ez az adó, ami SFN (Single Frequency Network) módban sugárzott. Ez azt jelentette, hogy egy-egy műsorcsomagot azonos frekvencián érhettünk el a két adóállomás esetében, így gazdaságosabban használva a frekvenciakészletet. 2002 májusában már vidéken is telepítettek ilyen adót, a Kabhegyen, ami a Budapesti műsorokat sugározta néhány helyi adóval együtt. Az országos (DVB-T) földi digitális televíziós műsorszórás 2008. december 1-én indult, de ezelőtt már számos digitális műholdas és kábeltévés szolgáltató is elkezdte már hazánkban a digitális adások terjesztését.

1.2. DVB Projekt A DVB Projekt ajánlásainak köszönhetően végül az alábbi szabványok kerültek kialakításra: DVB-T: (Digital Video Broadcasting - Terrestrial) digitális földfelszíni műsorszórás

6


DVB-H: (Digital Video Broadcasting – Handheld devices) digitális műsorszórás mobilkészülékekre DVB-S: (Digital Video Broadcasting - Satellite) digitális műholdas műsorszórás DVB-C: (Digital Video Broadcasting - Cable) digitális kábelhálózaton keresztüli műsorszórás Mielőtt belemennék ezeknek a részletezésébe, nézzük meg hányféleképpen foghatunk televíziós adást Magyarországon. Ha megnézzük a 2. ábrát, láthatjuk, hogy analóg adást kétféleképpen foghatunk, egyszer földfelszíni antennával így csak pár regionális és országos adót foghatunk, vagy kábelen keresztül, amit különböző műsorszolgáltatók szolgáltatnak, jóval nagyobb csatornaválasztékkal. Digitális adás fogásához is fogásához is megvan a lehetőségünk, akár földfelszíni antennával, műholddal, vagy kábelen keresztül. Ám itt jön egy fontos dolog, hogy ezeknek a vételéhez egy úgynevezett SET-TOP BOX-ra van szükségünk. Ezenkívül lehetőségünk van még digitális adás vételére IP TV-s technológiával is.

2. ábra: Digitális adás vételi fajtái

DVB-S (Digital Video Broadcasting - Satellite) A műholdak a földtől kb. 36000 km-re keringenek az egyenlítő síkjában egy geo stacionárius pályán, amelyek a digitális műsorszórást továbbítják. A keringési idejük 24 óra, ami a Föld keringési idejével azonos. Ezen az egy pályán akár több műholdat is el lehet helyezni megfelelő távolságra egymástól, más-más vízszintes irányszögek alatt. Ha a földről vizsgáljuk őket, megállapíthatjuk, hogy ezek látszólag egy helyen maradnak. Az Astra műhold például a 19,2 fokos keleti hosszúságnál található. 7


Mint már az előzőekben említettem a DVB-S átvitelt ajánlását 1994-ben fogadták el, amit az ETS 300421-es szabvány írt le. A DVB-S átviteli rendszer modulációjaként a kvadratúra –fázisbillentyűzést fogadták el, rövidebb nevén (QPSK). Egy csatorna sávszélessége a műholdas műsorszórásnál általában 26 és 36 MHz közé tehető. A downlink frekvencia 11 és 13 GHz , míg a uplink frekvencia 14 és 19 GHz között van. A QPSK moduláció esetén a teljes adatátvitel sebessége 55 Mbps, mivel két bittel továbbítható egy szimbólum, így a szimbólumsebesség kétszerese lesz (27,5 MS/s). A műholdas átvitelnél a szakaszcsillapítás eléggé jelentős. A földi vevő antenna és a műhold közötti nagy távolság miatt körülbelül 205 db-re tehető. A műhold jele, míg elér a vevőkészülékhez jelentős zajjal terhelődik és nagy mértékben csillapítódik.

DVB-C (Digital Video Broadcasting - Cable) A DVB-C szabványát is 1994-ben fogadták el, amit az ETS 300429 ír le. Itt is ugyanazon a jelfeldolgozási egységeken megy keresztül az MPEG-2 adatfolyam, mint a műholdas rendszereknél, de van egy kis különbség, mert itt elmarad a konvolúciós kódolás, mert a kábeles technikában a vételi minőségi jellemzők sokkal jobbak a műholdasnál. A DVB_C a QAM modulációt használja, melynek öt fajtája közül választhatunk. Ezek: 16, 32, 64, 128, 256 QAM. A koaxális vezetékeknél 64 QAM-et használnak , mert ez a legoptimálisabb a zajok , zavarok miatt. Az optikai kábeleknél viszont 256QAM-et, mert itt nagyon kicsi a zaj, zavar. Mára már megjelent a DVB-C2 szabvány is , ami már tartalmazza az MPEG-4 dekódert és HDTV kompatibilitást biztosít, de ez már az MPEG-2-nél is megvolt.

DVB-T (Digital Video Broadcasting - Terrestrial) A DVB-T a digitális sugárzásnak köszönhetően jobb képminőséget, hangminőséget, megbízható zavarmentes vételt és nagyobb műsorválasztékot biztosít az analóg adásokhoz képest. Ez a digitális műsorszórás VHF-UHF sávban történik. A DVB-T szabványt 1995-ben fogadták el, aminek a jellemzőit az ETS 300744 írja le. Először NagyBritanniában kezdték el a sugárzást, de 2003–ra már több országban is elkezdték a használatát. Hazánkban, mint már említettem 1999. június 9-én kezdték el a kísérleti adásokat az Antenna Hungária RT-nek köszönhetően. Majd egyre több helyre telepítettek ilyen digitális műsorszórásra alkalmas adókat. 2002-ben Kab-hegy és Szentes-re. 2009-re a lefedettség elérte a 88%-ot, ami már nagyobb volt, mint az analóg adások 86%os lefedettsége. Ez újabb 8 adótornyot jelentett. Mára már 95% körül van a lefedettség. A kódolásnak hazánkban az MPEG-4-et választották.

8


1.3. Az IP-alapú műsorszórás ismertetése Az IPTV, ahogy neve is mutatja, internetes protokoll alapú televíziózást jelent. Ebben a részben az IPTV rendszerről, tulajdonságairól, jellemzőiről lesz szó.

Az IPTV története Az IPTV-s közvetítések 1994-ben jelentek meg. Az amerikai ABC csatorna World News Now című műsora volt az első, ami - ebben az évben - a CU-SeeMe nevű videokonferencia-szoftverrel interneten keresztül is nyomon követhető volt. Az IPTV kifejezés a Precept Software által egy évvel később megjelent, de igazából 1998 volt az az év, amikor az első izmosabb előd megszületett: úgy döntött az AudioNet webes rádió, hogy megpróbál tévéadást is sugározni, és sikerrel járt. 1999 szeptemberében az angol Kingston Communications már komplett IPTV alapú tévészolgáltatással rukkolt elő. A Total Access Networks Inc. jóvoltából 2003-ban a világ 100 országában lehetett IPTV szolgáltatást igénybe venni, ugyanennyi, összesen 26 nyelven megszólaló adóval. Az AT&T 2006-ra már háromszor ennyi csatornát kínált. Ezt követően már nem érdemes számokkal dobálózni, mivel rengeteg olyan csatorna van, ami az IP protokoll alapú televíziózással elérhető. Kétfajta csomagot különböztetünk meg az IPTV-nél. Az egyiket, mint egy önálló szolgáltatásként is igénybe vehető csomagot, a másikat mint Triple-Play csomag által nyújtott szolgáltatást. 2006 júniusától az IPTV csatornák darabszáma meghaladta 1300-at. A televíziózás ezen ága rohamos gyorsasággal fejlődik, így a televíziós műsorszolgáltatók is egyre inkább arra törekednek, hogy adásaik az interneten is elérhetőek legyenek. Az IPTV szolgáltatás igénybe vételének a feltétele szélessávú internet hozzáférés, és az IPTV-n keresztül elérhető média megtekintésére alkalmas berendezés. Ilyen, például a számítógép, iPod, HDTV vagy akár egy 3G-alapú mobiltelefon is. Az első független IPTV szolgáltató ami a mariposaHD névre hallgatott, 2005 decemberében kezdte meg működését, amely HDTV formátumban nyújtotta adásait. Az Egyesült Államokban számos internetes oldal hirdet ingyenesen elérhető csatornákat, melyek olyan népszerű filmeket adnak, mint például Eltűntek és a Született feleségek, amely azt jelzi, hogy az IPTV egyre inkább előtérbe kerül.

Főbb jellemzői A csatornák digitális műsorszórás esetén multiplexelve vannak ezért szokás multiplexeknek nevezni őket. Több egymás után következő MPEG tömörített adásból áll egy multiplex, így egy adott frekvencián egyszerre több műsor továbbítására van lehetőség a digitális rendszereknél. Az ilyen típusú továbbítást broadcast-nak hívják. Broadcast továbbításnál a frekvencia spektrumot továbbítva az összes felhasználó megkapja az elérhető adásokat. A csatornaléptetés a vevőkészülék frekvenciák közti gyors áthangolásával valósítható meg. 9


A digitális sugárzással ellentétben az IPTV-nél nincsenek csatornák, mivel nem az egész spektrum kerül továbbításra, hanem csomagok formájában kerülnek elküldésre a különböző adók műsorai. Ennek az előnye, hogy szabályozni lehet melyik felhasználó melyik műsort kapja meg, amennyiben igényt tart rá. Az ilyen továbbítási módot unicast vagy multicast továbbításnak nevezzük. Unicastnál minden felhasználó dedikáltan kapja a kívánt tartalmat, a multicastnál pedig egy úgynevezett multicast group-on át jut el a tartalom a felhasználóhoz. Ez ezért előnyös, mert csökkenti a hálózat terheltségét a szolgáltató és a kliens között. Unicastot nem szívesen alkalmaznak a szolgáltatók, a terheltség elkerülése végett, de vannak bizonyos szolgáltatások, amiket csak unicastal lehet megvalósítani, ilyen például a VoD. Ennél a rendszernél nagyon a biztonság így egy adott tartalomhoz csak a jogosultak juthatnak hozzá. Az IPTV magába foglalja a digitális televíziózás összes előnyét, sőt ezen felül még többletszolgáltatásokat is biztosít a felhasználók számára, de ezeknek a szolgáltatásoknak a feltétele a kétirányú kommunikáció, ami az IPTV-nél adott, mivel kizárólag IP hálózaton továbbítható. Ebből a szempontból előnyt élvez az IPTV, mert a DVB rendszereknél a kétirányú kommunikáció megvalósítása nehézkes, kivéve a DVB-C-t ha a kábelrendszer engedi a visszirányt is. Számos kiegészítő szolgáltatást vehetünk igénybe a kétirányú kommunikáció segítségével. Például a képernyőn keresztül internetezhetünk és az összes ezzel járó előnyöket élvezhetjük, köszönhetően a set-top-box-ba beépített szoftvereknek. Telefonálhatunk, igénybe vehetünk különböző üzenetküldő szolgáltatásokat, webkamera megléte esetén akár videó hívásokat is lebonyolíthatunk. Vezeték nélküli egér és billentyűzet használatával még kényelmesebbé tehetjük ezen szolgáltatások használatát. A továbbiakban nézzünk meg néhány fontosabb fogalmat és szolgáltatást, amit jó ha ismerünk. Ilyenek például a Triple-Play, a VoD (Video on Demand) és a Pip (Picture in Picture).

Triple-Play A Triple-Play az internet, a TV, és a telefon együttes szolgáltatására használat fogalom. A lényege, hogy a három legelterjedtebb távközlési alapszolgáltatást, azaz a tévét, az internetet és a telefont az ügyfél ugyanazon szolgáltatótól veszi igénybe. Az ilyen szolgáltatásokért általában valamilyen kedvezményt kap az ügyfél, mintha azokat külön igényelnék, ezzel ösztönözve, hogy minél több ügyfél rendelje meg. A Triple Play fogalma a technológiai fejlődés eredményeként napjainkra már a mobilszolgáltatásokra is kiterjed. A 3G/4G/HSDPA - hálózatok lehetővé teszik a gyors mobilinternet, mobiltévé használatát, így elérhetővé téve a Triple-Play-t vezeték nélküli szolgáltatók esetében is. Amennyiben a Triple-Play mobil technológiát is alkalmaz, Double-Triple-Play-nek vagy QuadruplePlaynek nevezzük. 10


VoD – Video on Demand A VoD mint ahogy a neve is mutatja, olyan szolgáltatás, ahol igény szerinti videó és hanganyagokat, filmeket, archivált eseményeket, tudunk egy központi adatbankból letölteni, a nap bármelyik időpontjában. A letöltés dedikált útvonalon IP streaming-el történik. A szolgáltatók rengeteg videót, műsort és mindenféle anyagot rendelkezésre bocsájtanak, de ezekért külön fizetni kell a szolgáltatónak. A VoD tartalma titkosított formában kerül elküldésre. Egy műsor megtekintéséhez nem szükséges megvárnunk, míg az ténylegesen letöltődik, hanem már a letöltés megkezdésekor is nézhetjük. Lehetőségünk van a film megállítására, előre-, hátra tekerésére, a Real Time Streaming Protocol használatának köszönhetően. A VoD-ban az MPEG-2, MPEG-4 kódolási formát használják legtöbbször.

Pip - Picture in Picture A kép a képben egy újabb funkció, amit az IPTV nyújt a nézők számára. Lényege hogy több csatorna adását egy időben, mátrixszerű elrendezésben lehetőségünk van áttekinteni. Ehhez csak az kell, hogy több multicast grouphoz csatlakozzunk a set-top boxal és az már szoftveresen előállítja nekünk ezt a funkciót. A gazdaságosság érdekében a PiP funkciókhoz külön szervereket biztosítanak, amik a lebutított adást továbbítják, csökkentett felbontással, kisebb sávszélességgel.

11


2. IPTV adatfolyamok bemutatása 2.1. Forráskódolás AZ IPTV adatfolyamánál az MPEG szabványait használják tömörítésre. A Moving Picture Coding Experts Group-ot, azaz a mozgókép tömörítéssel foglalkozó szakértői csoportot 1988. januárjában alapították. Az ISO/IEC keretében működik. Céljuk egy általános szabvány megalkotása volt a videó anyagok, hanganyagok és audió-vizuális anyagok számára.

MPEG-1 Az MPEG-1 szabvány szerinti tömörítés alapja a JPEG eljárás. A képkockán belüli kódolásra sok algoritmust a JPEG tömörítésből vesz át. Ilyen algoritmusok például a kvantálás, a delta koszinusz transzformáció. Az MPEG-1 ezen felül az egymást követő képkockák képi redundanciáját is csökkenti. Mozgáskompenzációs eljárások segítségével igen jelentős tömörítési arányt lehet kihozni belőle. A JPEG-en alapuló algoritmusok a mozgáskompenzációs eljárások után kerülnek végrehajtására. Különbség még a JPEG és az MPEG között, hogy az MPEG hangadatot is tömörít. Sávszélessége kb. 1,5 Mbps-ra tehető, mely egy PAL jelet 25 kép/sec képfrissítésnél, alacsony (352×288) felbontással továbbít.

GOP – Group of Pictures Az MPEG-1 szabvány három különböző tömörített képfajtát határoz meg. Ezek az I, P, és B képkeretek. Szokás I-, P-, és B-Frame-eknek is nevezni őket. Két I-kép által határolt képek összességét képcsoportnak (Group of Pictures, GOP) nevezik. Ennek hosszúsága különböző lehet. Egy GOP felépítését a 3. ábrán láthatjuk. A továbbiakban a különböző képkereteket mutatom be. I-Frame: (Intra-frame coded), mint ahogy a neve is mutatja az i-frame-ek belső kódolásúak, azaz csak a képen belüli információkat használja a tömörítés során a feldolgozásra. Az I-frame-k periodikus használata nélkül nem lenne lehetséges a videó anyag egyes részeihez való hozzáférés. Az átviteli hibák halmozódását is ezek a framek hivatottak megelőzni. Az egyes képkockákon belül JPEG tömörítést alkalmaznak. Ennél a típusú képkeretnél a legkisebb a tömörítési arány. P-Frame: (Predicted pictures) p-frame előállítása mozgáskompenzációval kombinált előrelátható predikcióval történik, úgy hogy az információt az előtte lévő I vagy P frameből nyeri ki. Tehát a megelőző I, vagy P-kép képrészleteinek elmozdulását, illetve a képtartalmak közötti különbségeket rögzíti. Azt használja ki, hogy az objektumok alakja a mozgás során nem változik, így két egymást követő képkockán sem. Csak az eltérő alakok információit és színinformációkat tartalmazzák. Továbbá mozgásvektorokkal helyettesítik az objektumok elmozdulását. P-frame-ekkel már jóval nagyobb tömörítési arány érhető el, de nem alkalmasak vágási referenciaként való használatra. Ennek magyarázata, hogy P12


frame származhat előző P-frame-ből is, ami hibát is tartalmazhat, így hibák halmozódásához vezethet. B-Frame: (Bidirectional pictures) kódolásánál a P-frame-ekkel ellentétben nem csak a megelőző, hanem a következő I és P-framek adatait is felhasználja referenciaként. Ez csak kódolási sorrend megváltoztatásával lehetséges. A legnagyobb arányú tömörítést ezzel a képkerettel lehet elérni, de a feldolgozása jóval időigényesebb. Nem használhatók referenciaként a jósláshoz és természetesen a vágáshoz sem. Egy GOP kezdődhet Bframe-el, de nem érhet véget azzal.

3. ábra: GOP felépítése

MPEG-2 Az MPEG-2 az MPEG-1 továbbfejlesztett változata. A DVB Projekt a digitális műsorszórás forráskódolásának az MPEG-2-őt választotta. Az MPEG-2 kódolás esetén a képsebesség 2-6 Mbps, a hangsáv pár száz kbps közé tehető. DVD lemez esetén a teljes adatsebesség 9 Mbps körül mozog, de digitális műsorszórásnál ez az érték valamivel alacsonyabb. A szabványos 8MHz méretű csatornán lehetőség van több tv adás-t is továbbítani. DVB-S esetén 38 Mbps körüli adatsebességet is el lehet érni és ugyanezt az adatsebességet egy 8 MHz-es DVB-C csatornán is elérhetjük a 64QAM moduláció segítségével. Az MPEG-2 tartalmaz még úgynevezett információs táblákat, ami az adatfolyam tartalmáról hordoz információkat. Mivel egy bizonyos vételi szint alatt a digitális adás feldolgozhatatlanná válik, bevezették az MPEG-2-nél a skálázhatóságot. Ez azt jelenti, hogy különböző minőségű adásokat vihetünk át. Például van egy alap csatornánk rosszabb képminőséggel és van egy erre ráépülő kiterjesztett csatornánk jobb képminőséggel. Így rosszabb vételi körülmények között nem az egész adás válik nézhetetlenné, hanem csak a minősége romlik le. HDTV esetén például van egy alap SDTV minőségű csatornánk, amire ráépül egy kiegészítő csatorna, ami HDTV felbontásra javítja fel a képet. Az MPEG-2-nél definiáltak különböző profilokat (4.ábra) és szinteket (5.ábra) is, mivel több különböző beállítása is lehetséges. MPEG-2 profilok

13


SP

egyszerű profil, I,P, 4:2:0, nem skálázható

MP

fő profil, I,P,B,4:2:0, nem skálázható

MVP

több kameraállás, I,P,B, 4:2:0

422P

4:2:2 profil, I,P,B, 4:2:0/4:2:2, nem skálázható

SNR P

jel-zaj viszony skálázhatóság, I,P,B, 4:2:0

HP

nagyfelbontású profil, I,P,B, 4:2:0/4:2:2, térbeli v. SNR skálázhatóság

SSP

térbeli skálázhatóság, I,P,B, 4:2:0, SNR skálázhatóság

4. ábra: MPEG-2 profilok MPEG-2 szintek

szintek

maximális felbontás képpont

maximális bitráta (MBps)

LL

352×288

4

ML

720×576

15

H14

1440×1152

60

HL

1920×1152

80

képfrekvencia (Hz)

23,976 24 25 29,97 30

23,976 24 25 29,97 30 50 59,94 60

5. ábra: MPEG-2 szintek Az egyszerű profil (SP) nem használ B frameket, így nincsen kétirányú előrejelzés (Bidirectional prediction). Olyan esetekben használják ahol fontos az alacsony késleltetés, például videokonferenciák esetében ahol a késleltetés nem haladhatja meg a 100 ms-t. A Fő Profil és Fő Szint (MP és ML) együttes alkalmazása a leggyakoribb. Ilyen beállítás mellett 2-15 Mbit/s átviteli sebességű, nem skálázható, SD felbontású (720*576), 4:2:0 szín mintavételezésű, I, P és B képeket használó adatfolyamot továbbítható. A fő profilnál a késleltetés 120 ms-re tehető. Ez a profil lefelé kompatibilis az MPEG-1-el.

14


A HP profil a nagyfelbontású adások továbbítására, a 4:2:2-es profil pedig a 4:2:2-es rendszereknél alkalmazott videóknál használható. Az SNR profil a zajos átviteli közegeknél előnyös a jó jel/zaj viszonya miatt. Az MPEG-2 négyféle kódolási szintet határoz meg képfelbontás, bitráta, képfrekvencia, és puffer méret szerint. Adatátviteli sebessége rugalmasan skálázható. Egy fontos újítást vezettek be az MPEG-2nél, mégpedig, hogy a MPEG-1-nél használt 1:1 arányú pixelekből álló kép helyett az MPEG-2-nél már változtatható a képpont oldalarány(Pixel aspect ratio), így téglalap alakú pixelekből is felépülhet egy videó. A fejlécben határozható meg a kép oldalaránya (Aspect ratio) melynek értékei lehetnek: hagyományos (4:3) és szélesvásznú (16:9, 2,21:1). MPEG-2 - Group of Pictures: Az MPEG-2 kódolásnál a GOP-ok, azaz képcsoportok, különböző szekvenciákkal fordulhatnak elő. Az egy GOP-ban előforduló I, P, és B Framek számát a kódoló határozza meg. Az I,P,B képkerete száma nagyban befolyásolja az átviteli sebességet és a videó képminőségét is. Két számmal írható le egy GOP struktúra az N és az M számmal. Két I Frame közötti távolságot jelöli az N szám. Egy GOP tovább bontható úgynevezett SubGOP-okra, ezekben az is és P közötti intervallumot jelölik az M számmal. Általában egy MPEG-2-es videó két I Framet tartalmaz egy másodperc alatt. NTSC rendszerekben gyakori az N=15 , PAL rendszerekben pedig az N=12 beállítás.

MPEG-4 Az MPEG-2 után az MPEG-3 bevezetése jött volna, amit a HDTV-re szántak, de rájöttek , hogy ez az MPEG-2-vel is megvalósítható. Az MPEG-4 objektum orientált felépítésű lett, hasonló a c++ nyelvre és interaktív elemeket tartalmaz. Kétszer hatékonyabb lett az elődjénél. Például egy MPEG-2 SD csatornájának 4-5 Mbps sebességéhez képest, az igényelt adatsebessége 1,5-2,5 Mbps-ra csökkent. Vagy egy HDTV csatorna esetén a 12 Mbps, helyett is csak körülbelül 6 Mbps adatsebességet igényel Alacsony bitsebességre lett tervezve, mobil hálózatokra, de ezt a nagyfokú tömörítését másra is használják. A DVB-T rendszereknél és a Blu-Ray lemezeknél is ezt a kódolást használják. Nagy újítást jelentett az MPEG-4 Advanced Video Coding (AVC) / H.264 szabvány megjelenése. Az ISO és ITU közösen létrehozott szabánya. Jelentős előrelépést értek el gyorsaság és hatékonyság szempontjából is. Amiben előrelépést hozott: • Egész értékű transzformáció • (deblocking filter) blokkosodás elleni szűrű • Hatékonyabb intra kódolás 15


• Hálózati környezetre való adaptálhatóság • makroblokk méret 16x16-tól egészen 4x4-es blokkméretig • egynegyed képpont pontosságú mozgásbecslés • Több referenciakép használata • Súlyozott kétirányú predikció Nagyfokú tömörítésének köszönhetően a bitsebesség akár a fele is lehet más szabványokhoz képest, ám a hátulütője hogy ezzel a kódolás és dekódolás erőforrás igenye a kétszeresére nő.

2.2. Transport Stream Az MPEG 2 rendszernek az adatátvitelre használt specifikációját Transport Stream-nek hívják. Egy TS egy vagy több egymástól független csatorna adatait is hordozhatja. De nézzük át előbb azt az elemi adatfolyamot ami a TS-eket is tartalmazza(PES).

PES - Packetized Elementary Stream A PES tulajdonképpen az MPEG kódolás után létrejövő adatoknak a csomagolt változata. A kódolt adatfolyamot Elementary Stream-nek (ES) nevezzük. Egy PES csomag hossza változó hosszúságú lehet. Az audio-video, a teletext és a PCR adatok összessége adja a PES-t .

6. ábra: PES felépítése Egy PES csomag fejléce 4 részből áll, mint a 6. ábrán is láthatjuk. Az első egy 3 bájtnyi start code, a második az adatfolyam azonosítója. A harmadik a PES csomag hossza, aminek ha mindkét bájtja a 0 értéket veszi fel akkor a csomag hossza meghaladja a 64 kilobájtot. A fejléc negyedik része a z opcionális fejléc, amely a DTS-t és a PTS-t tartalmazza. A DTS (Decoding Time Stamp) a képek eredeti sorrendjének visszaállításánál a PTS (Presentation Time Stamp) pedig a hang és kép szinkronba hozásánál játszik fontos szerepet.

TS - Transport Stream 16


A Transport Stream, röviden TS, állandó csomagmérettel rendelkezik. A 188 bájtos struktúra első bájtja a szinkronizálásra szolgáló szinkron bájt. Egy keret 8 TS.ből áll melyben az utolsó TS szinkron bájtja negáltan szerepel. A hibajavítás végett egy 16 bájtos reed-solomon kódot is kap egy TS csomag. A továbbiakban ismertetem egy TS csomag tartalmát (7. ábra).

7. ábra: TS csomag felépítése Sync: (Szinkron bájt) Minden egyes TS szinkronbájttal kezdődik melynek mérete 8bit és a hexadecimális 47 értéket veszi fel. A szinkronizáció 5 csomag vétele után jön létre és 3 csomag elvesztése után szakad meg. Mivel előfordulhat, hogy ez az érték az adatok között is előfordulhat, ezért a helyességének megfigyelésére a két szinkron bájt közötti távolságot is nézi a vevő, hogy meg van-e a 188 bájt. Transport Priority: Priorítás jelző bit. A csomagoknak lehet ugyanaz a csomagazonosítójuk, de ilyenkor az egyik csomagnál a prioritás jelző bit értéke 1 kell hogy legyen, ezzel jelezve hogy fontosabb a másik csomagnál. Payload Start: Ennek a bitnek a segítségével tudhatjuk meg, hogy egy kapott csomag hasznos adatainak ez eleje egy PES fejléc vagy egy tábla fejlé-e. Ha a kettő közül valamelyik akkor a bit értéke 1-es. Error indicator: Az átviteli hibák jelzésére szolgáló bit. Mint az említettem egy csomag egy 16 bájtos reed-solomon kódolást is kap, aminek köszönhetően 8 bájtnyi hiba javítására képes. De ha ennél több hiba lépne fel, akkor ennek a bitnek az értékét 1-re állítják ezzel jellezve, hogy a csomag felhasználhatatlan. Packet Identifier (stream ID): Ebbe a 13 bites részbe kerül a csomagazonosító, röviden PID. Scrambling Control: Két bit hosszúságú rész, mely azt jelzi, hogy a hasznos adatrészben lévő adatok titkosítottak-e vagy sem. Ha mindkét bit értéke 0, akkor nem titkosított, ha valamelyik bit 1-es akkor titkosított. 17


Adaptation Field: (Adaptációs mező) Értéke 1, ha van adaptációs mező, és 0, ha nincs. Continuity Check Index: A fejléc utolsó 4 bitje a folyamatosság számláló, mely 0 és 15 között vehet fel értékeket. Értéke egy csomag megérkezésénél egyel nő. A számlálás folyamatosságának figyelésével az esetleges hibák kiszűrhetőek. Optional Adaptation Field: (Opcionális adaptációs mező) Fontos szerepet játszik, mivel itt találhatóak azok az információk amik segítenek az adó és a vevő összehangolásában. Itt található a PCR. A PCR (Program Clock Reference) felelős az adó oszcillátorának és a vevő oszcillátorának szinkronizálásáért, mivel a helyes vételhez elengedhetetlen, hogy az adó és a vevő órajele azonos legyen. Ezt egy 33+9 bites számmal valósítják meg. A szinkronizációhoz a rendszer órajelet használják (27MHz).

További fontosabb táblák A táblák osztályozását két részre oszthatjuk. Az egyik a PSI, program specifikus információk, melyekben az adatfolyam szerkezetéről, a programok, elemi adatfolyamok számáról kaphatunk információkat. Fontosabb táblák a PSI-ben, melyeket az alábbiakban részletesebben tárgyalok: PAT, PMT, CAT, NIT. Ezek a táblák mind a TS hasznos adatrészében kerülnek elküldésre és az MPEG-2 szabvány jelzési táblázatai. A táblák osztályozásánál a másik rész a DVB szabvány által hozzárakott jelzési táblázatok, az SI, szolgáltatási információk. Ilyenek például az BAT, SDT, TDT, RST, EIT. A sok rendszer információk és jelzési táblák miatt hogy rendet teremtsenek, külön szabványt hoztak létre DVB-SI. Itt meghatározták minden egyes táblának milyen értékű PID csomagban a helye. Erre a célra a 0-től 31-ig terjedő PID-eket foglalták le. A 8. ábra ezek a PID-eket és funkcióikat írja le. PID 0

Funkció Program Association Table (PAT)

1

Conditional Access Table (CAT)

2

Time & Date Table (TDST)

3-15

fenntartva

16

Network Information Table (NIT)

17

Service Description Table (SDT), Bouquet Association Table (BAT)

18

Event Information Table (EIT)

19

Running Status Table (RST)

20 21

Time & Date Table (TDT), Time Offset Table (TOT) Network szinkronizáció 18


22-29

fenntartva

30

Discontiunity Info Table (DIT)

31

Selection Info Table (SIT)

8. ábra: Lefoglalt PID-ek és funkcióik

PSI – Program Specific Information PAT (Program Association Table): A PAT táblák az egyes például tévé- vagy rádióműsorok adatait leíró PMT-k PID-jeit tartalmazzák. Így ezekből megkaphatjuk adott streambe a műsorok számát is. Ezeket a táblákat meghatározott időközönként be kell illeszteni a TS-be. Ennek PID-je mindig 0 értékű. PMT (Program Map Table): Ez a tábla tartalmazza az egy csatornához tartozó PIDeket. Ilyenek például, a hangnak, a képnek, a teletextnek a PID-jei. Sőt a PCR PID-je is megtalálható itt. Tartalmaz egy mutatót is, ami az adott csatorna STD-jére mutat rá. CAT (Conditional Access Table): Ha az adásunk kódolt, akkor ennek a dekódolásához a CAT tábla nyújt nekünk információkat. NIT (Network Information Table): Ebben a táblában találhatók egy adott programcsomaghoz tartozó hálózatnak a különböző adatai. Ilyenek az átviteli csatorna adatai, a használt frekvencia sávok, amiket a Network Search engedélyezése után ennek a táblának a segítségével talál meg a vevőkészülék. Vagy például a csatornánál használt moduláció. Ez a tábla is tartalmaz egy azonosítót, a NID-et, amellyel egy adott szolgáltatóhoz tartozik.

SI - Service Information BAT (Bouquet Association Table): Ebben a táblában kerülnek kategorizálásra az egyes csatornák, témájuk alapján, például zene, sport vagy film. SDT (Service Description Table): Minden adatfolyamhoz, legyen az tévé, rádió, tartozik egy leíró tábla. Ebben található információk a szolgáltatás típusáról, az üzemeltető és a műsor nevéről. TDT (Time and Date Table): Ennek a táblának az alapján jelenítik meg a csatoknák a pontos időt (GMT), bár némelyik csatornánál ez is eltér a valóságtól. EIT (Event Information Table): Ez a tábla tartalmazza az egyes csatornák különböző műsorainak a nevét, azoknak kezdési és végzési időpontját, időtartamukat. Ebből a táblából nyeri ki az adatokat az EPG és állítja elő az elektronikus műsorújságot.

2.3. Internet Protocol Az internet világméretű hálózatának fő szabványa az IP, internet protokoll nevet kapta. Ezen protokoll segítségével kommunikálnak az internet-re kapcsolt csomópontok (számítógépek, hub-ok, routerek,). 19


Főbb jellemzői Az Internet Protokoll az OSI modell szerint a hálózati réteghez tartozik. Csomagkapcsolt hálózati forma, ami azt jelenti, hogy nem épít fel kapcsolatot a forrás és a cél között. Minden egyes hálózatra csatlakoztatott eszköz rendelkezik egy 32 bites azonosítóval, IP-címmel. Az IP-cím két részből tevődik össze, az egyik a hálózatot, a másik pedig a hoszt-ot, a hálózatra csatlakoztatott eszközt azonosítja. Ezeknek a különböző méretű felosztásával 4 osztályt alkottak meg plusz egyet későbbi használatra. Ezeknek a felépítése a 9. ábrán jól látható.

9. ábra: IP cím osztályok

Tehát ha valamelyik eszköz kommunikálni szeretne az interneten egy másik eszközzel, akkor egy IP datagramot küld a címzettnek, melyben megtalálható a saját és a címzett gép IP címe. Lehetőségünk van nem csak egy címzettnek, hanem akár többnek is egyszerre üzenetet küldeni. Ez alapján 3 fajta küldési módot különböztetünk meg: az unicast, broadcast, és multicast címzést. Az unicastnál csak 1 címzettnek, a broadcastnál mindenkinek és a multicastnál korlátozottabban bizonyos csoportnak megy a küldés.

IP Datagram felépítése Minden egyes IP datagram rendelkezik egy fejléccel, ami nagyon fontos információkat tárol a küldendő csomagról(10. ábra). Az alábbiakban ennek a felépítését fogom részletezni.

10. ábra: IP fejléc felépítése.

20


Verzió: a datagram protokoll verzióját adja meg, ami lehet IPv4-es vagy IPv6-os is. Jelenleg e két verzió között zajlik az átmenet. IHL: a fejrész hossza változó méretű lehet, ezért ennek a megadására szolgál az IHL. Legkisebb értéke 5 lehet, ilyenkor nincs opció, legnagyobb pedig 15, ilyenkor van opció. Szolgálat típusa: arra használjuk, hogy különbséget tegyünk különböző szolgáltatási osztályok között.6 bites mező, de tulajdonképpen mára már csak 3 bitet használunk belőle. Ez a három bit a D,T és R rövidítést kapta. A D = Delay (Késleltetés), a T = Throughput (Átbocsátás), az R = Reliability (Megbízhatóság) megadására szolgál. Ennek alapján lehet eldönteni, hogy egy csomagnál a kisebb-nagyobb átbocsátóképesség, megbízhatóság vagy késleltetés a fontos. Teljes hossz: A datagram teljes hosszát adja meg. Fejrész + hasznos adatrész. Ennek maximális értéke 65535 bájt lehet. Azonosítás: ennek a mezőnek az alapján dönti el a hoszt a darabolt datagramok közül, hogy egy újonnan érkezett daragram melyik datagramokhoz tartozik. A feldarabolt datagram minden része ugyanazt az azonosítót kapja. DF: (Don’t Fragment) magyar jelentése: Ne darabold. Ez a parancsa a routereknek szól, hogy ne darabolják az érkező datagramot , ha ennek a mezőnek az értéke 1, mivel a cél nem tudja majd azt újból összerakni. MF: (More Fragment) magyar jelentése: Több darab. Arra szolgál, hogy megállapíthassuk, hogy a datagram minden darabja megérkezett-e. Az utolsó darabot kivéve minden darabnál az értéke:1, az utolsónál: 0. Darabeltolás: a datagram darabok sorba rendezésében segít ennek a mezőnek az értéke. Élettartam: egy számlálót tartalmaz, ami meghatározza, hogy egy adott csomag meddig maradjon életben, azaz mikor dobja el azt a router. Ilyenkor egy figyelmeztető csomagot kap róla a küldő. Ez az érték maximálisan 255 lehet, amit eleinte másodpercekre terveztek, de gyakorlatilag az ugrások számát jelenti. Protokoll: ebben a mezőben a szállításnak a protokollját adhatjuk meg, melyek általában vagy a TCP vagy UDP, de lehetnek más protokollok is. Fejrész ellenőrző összeg: csak a fejlécre vonatkozik, a fejléc védelmére szolgál. Forrás címe: A forrás gép IP címét tartalmazza. Cél címe: A cél gép IP címét tartalmazza. Opciók: Az opció mező a protokoll későbbi fejlesztése céljából hozták létre, hogy olyan információkat is át lehessen vinni, amik az eredeti protokollban nincsenek benne. Pár opció: Biztonság, Időbélyeg, Útvonal feljegyzése.

21


2.4. További fontosabb protocol-ok ARP - Address Resolution Protocol Ez a protokoll az IP címek feloldását hivatott végigvinni. Mivel az adatkapcsolati réteg hardvere nem ismeri az IP cím fogalmát, ezért az IP címeket le kell képeznünk fizikai címekre (MAC cím). Minden hálózatra kötött eszköz interfész kártyájának, ethernet kártyájának van egy egyedi címe, ethernet címe. Minden gyártó külön címtartományt kap, ami alapján minden kártyának külön 48 bites azonosítót adnak. Elméletileg nincs két egyforma címmel rendelkező kártya. Tehát ez a protokoll egy adott IP címhez hozzárendeli az azt használó eszköz ethernet kártyájának a MAC címét. Nézzük meg két gép esetén a címfeloldás lépéseit. Az 1. gép üzenetet akar küldeni a 2. gépnek. 1. lépés: az 1. gép adatszóró csomagot küld, ami tartalmazza a saját IP címét és MAC címét, valamint még egy ”kérdést”, hogy kihez tartozik az 2. gép IP címe, és egy MAC címet vár válaszul. Ezt a hálózaton lévő összes gép megkapja és mind el is raktározza az 1. gép IP és MAC címét, későbbi esetleges felhasználás céljából. 2. lépés: a megkapott csomagot minden gép átnézi és megvizsgálja, hogy neki szól-e a ”kérdés”. Csak a 2, gép fog válaszolni rá, és elküldi a saját IP címét és MAC címét, amit az 1. gép elraktároz.

UDP - User Datagram Protocol Az UDP – felhasználói datagram protokoll, egy összeköttetés - mentes szállítási protokoll, melynél nincs szükség kapcsolat létesítésére a feladó és a címzett között. A csomagok megérkezése nem garantált, sőt a sorrend is felborulhat. Nincs nyugtázás egy csomag beérkezéséről. Nem végez forgalomszabályozást, hibakezelést. Általában kliensszerver alkalmazásoknál előnyös a használata. Az UDP szegmensek egy 8 bájtos fejlécből és felhasználói adatokból épülnek fel (11. ábra).

11. ábra UDP csomag formátum

22


Az UDP használatának előnye, hogy a fejlécben a címzésnél megadható a forrás és a cél port címe is. Ezeknek a mezőknek a hiányával a szállítási réteg nem tudná kezelni a csomagokat. A gép a port számokat használja ahhoz, hogy melyik csomagot melyik program kapja meg, mivel egyszerre több program is kommunikál az ethernet kártyánk segítségével. Egy port 16 biten tárolódik, így 65536 darab portot különíthetünk el. Egy UDP fejléc a következő mezőkből áll: Source Port: Forrásport, ha válaszküldésre van szükség, akkor használják ezt a portot, innen nyerik ki, hogy melyik portra kell a választ küldeni. Destination Port: Célport, a cél gépnek melyik portjára kell küldeni a csomagot. Message Length: UDP szegmens hossza, a fejléc és az adatmező együttes hosszát tartalmazza. Checksum: UDP ellenőrző összeg a csomaghoz. Valós idejű adatküldésnél mutatkoznak meg az UDP előnyei vagy kis méretű csomagok küldésénél és olyan rendszereknél ahol nem okoz globális hibákat minimális mértékű csomagvesztés. Sokkal gyorsabban végzi el a kisebb csomagok küldését, mint a TCP/IP protokoll, ezért kifejezetten jó kis csomagméretű adatok küldésére, mint például idő szinkronizáció. Ezenfelül számunkra az egyik legfontosabb tulajdonsága, hogy támogatja az egy pontból több pontba irányuló kommunikációt, tehát IPTV szolgáltatásokhoz kifejezetten előnyös.

ICMP: (Internet Control Message Protocol) Az ICMP – internet vezérlőüzenet protokollt az internet ellenőrzésére használják a routerek segítségével. Ha váratlak hiba lép fel azt ICMP-vel jelentik. Számos előre definiált ICMP üzenet létezik. Ezek közül felsorolnék párat: Cél elérhetetlen, Időtúllépés, Paraméter probléma, Forráslefojtás, Átirányítás. Ezek csak néhány a fontosabb üzenetek közül, ezenkívül még számos üzenet létezik. Minden egyes ICMP üzenet IP csomagba ágyazva kerül elküldésre.

IGMP - Internet Group Management Protocol Az IGMP az egyik már régóta használt multicast-al foglalkozó protokollok közé tartozik. Mielőtt bemutatnám az IGMP protokollt, pár szót írnék a többesküldésről, azaz multicast üzenetekről. Az Internet Protokollnál a multicast továbbítás a D osztályú címeket használja, amelyek mind egy-egy hosztcsoportot azonosítanak. 28 bitet használnak a csoportok azonosítására. Egy D osztályú címre való multicast üzenetnél előfordulhat, hogy valamelyik hoszt nem kapja meg az üzenetet.

23


Az IP kétfajta csoportcímet különböztet meg: ezek az állandó és az ideiglenes címek. Egy állandó csoport mindig létezik, nem szűnik meg és az ilyen csoportoknak a címük is mindig állandó marad. Tekintsünk meg néhány ilyen állandó csoportot: 

224.0.0.1 Egy hálózaton levő összes rendszer



224.0.0.2 Egy hálózaton levő összes router



224.0.0.5 Egy hálózaton levő összes OSPF-router



224.0.0.6 Egy hálózaton levő összes kijelölt OSPF-router

Az ideiglenes csoportokat létre kell hozni, mielőtt használhatnánk őket, ezekhez csatlakozhatunk, kiléphetünk belőlük, de ha már az utolsó tag is inaktív lesz a csoportban, akkor ez a csoport megszűnik a hoszton. A többesküldést a régebbi routerek nem feltéltenül tudják kezelni, de ma már alapkövetelménynek számít. A többesküldéshez multicast routereket használnak. Ha egy kliens egy multicast csoporthoz szeretne csatlakozni, akkor fel kell iratkoznia az adott hálózat routerénél. Ez a regisztráció IGMP üzenetek segítségével történik IPv4-es hálózat esetén. IGMP Query üzenetek periodikus küldése megy végig a hálózaton. A 224.0.0.1.-es címre történik a küldés. A multicast routerek a Query-re adott válasz alapján (IGMP Report) meg tudják állapítani melyik kliensek tartoznak egy adott csoporthoz. Ha van olyan csoport a hálózaton, amelynek már egyetlen aktív tagja sincs, akkor a routerek leiratkoznak a csoportról (Leave Group üzenetek). Az IGMP üzenet fajták: IGMP Membership Query: Egy multicast router küldi ezt az üzenetet. Ennek a válasza alapján határozza meg a router hogy a kliensek milyen adatokat kapjanak. IGMP Membership Report: Ez az üzenet az IGMP Query-re adott válasza a klienseknek. Tartalmazza, hogy egy kliens melyik multicast group-hoz tartozik, vagy melyikhez szeretne csatlakozni. Egyszerre több válasz esetén az ütközés elkerülése végett késleltetést iktattak be. IGMP Leave Group: A multicast csoportból való kilépéshez használt üzenet.

24


3. Vezeték nélküli átviteli módok ismertetése Ősidők óta törekedtek az emberek a vezeték nélküli kommunikációra, például az indiánoknál a füstjelzés használták, a tengerészeknél a fényjelzéseket használták az ilyenfajta kommunikációra. De a vezeték nélküli hálózatok gyökere a 2. világháborúig vezethető vissza. Itt már a katonaság próbált rádió jelek segítségével adatokat átvinni és ez a próbálkozás sikerrel is járt. Az itt elért eredmények arra inspiráltak a fejlesztőket, kutatókat, hogy kidolgozzák a legelső nyílt csomag alapú, rádiófrekvenciát használó adatátviteli technológiát. Erre a Hawaii Egyetemen került sor. Az első ilyen vezeték nélküli hálózat az ALOHNET nevet kapta, mely 7 számítógépből épült fel.

WiFi A Wi-Fi, a vezeték nélküli rádióhullámú kommunikációt megvalósító, az IEEE által fejlesztett, IEEE 802.11-es szabványra használt népszerű név. Mára már nagyon sok háztartásban elérhető, a szükséges készülékek ára jócskán leesett az évek során. Rengeteg készülékbe beépítik manapság, pl: tv, telefon, tablet. Használhatjuk internetezésre, de már IPTV szolgáltatásokra is, az új szabványoknak és a gyors sebességnek köszönhetően. Az IEEE az 1997-es első 802.11-es szabvány megalkotása óta számos szabvánnyal bővült.

IEEE Szabványok Az alábbiakban bemutatnék pár IEEE által fejlesztett és jóváhagyott vezeték nélküli kommunikációra használt szabványt és még egy fejlesztés alatt álló szabványt.

802.11a Az első nagysebességű vezeték nélküli LAN szabvány, mely az 5 GHz-es frekvenciát használja. A nagy sebességet az OFDM-nek (Orthogonal Frequency Division Multimplexing) köszönheti, mellyel akár 54Mb/s-os adatátviteli sebességet is el tud érni. 52 különböző frekvenciát használ, ebből 4-et a szinkronizációhoz, a többit az adatokhoz. A több keskeny sávnak számos jó tulajdonsága van például a jobb interferenciatűrés. A kódoláshoz a QAM modulációs eljárást használják. Az 5GHz-es eszközök drágasága miatt nem olyan széles körben használják.

802.11b Ez a szabvány a 2,4 GHz -es frekvenciatartományt használja. Mondhatni a legelterjedtebb szabványok egyike. Itt gyakrabban előfordulhat interferencia, mivel számos eszköz ezt a frekvenciatartományt használja, például vezeték nélküli telefon, kapunyitó, mikrohullámú sütő. A sávszélessége 11Mbit/s, ami elég lassúnak számít manapság, IPTV-s adás átvitelére nem alkalmas. A HR-DSSS (High Rate Direct Sequence 25


Spread Spectrum) eljárást alkalmazza. A 802.11b szabványnál lehetőségünk van az átviteli sebesség változtatására.

802.11g A 802.11b továbbfejlesztett változata, mely a szűkebb 2,4 GHz-es tartományt használja, 802.11a-val szemben. Működését tekintve megegyezik a 802.11a szabvánnyal. Szintén az OFDM eljárását használja, mint a 802.11a, aminek segítségével az adatátvitel sebessége akár az 54 Mb/s-os sebességet is elérheti. Ez a rendszert már képek, filmek , adatok átvitelére és a számunkra fontos IPTV-s műsorszórásra, IPTV adások vételére is alkalmas.

802.11.n A 802.11n szabvány az alap 802.11 szabvány kiterjesztése a MIMO-val. Hogy mi is a MIMO? A MIMO (Multiple In, Multiple Out) egy többantennás rendszer, amely ellentétben a normál vezeték nélküli hálózatokhoz képest, nincsenek hatással rá a visszavert jelek, nem zavarják a működését, hanem éppen ellenkezőleg a hatósugár kiszélesítésére használják fel a reflektált jeleket. Így elérhetővé téve az eddig elérhetetlen pontokat. A jelek akár négyszer távolabb is eljuthattnak a 802.11g szabvány jeleihez képest. Definiáltak egy több antennából álló rendszerek számára tervezett absztrakt matematikai modellt, ez a MIMO Spatial Division Multiplexing . Itt az adó és a vevő oldal is több antennából épül fel és az adatok továbbítása is egyszerre több antennán történik. Akár 300 Mb/s-os sebességet is elérhetünk az ilyen rendszereknél. A szabvány OFDM-et használ ahol 52 darab 300kHz-es subvivőkre osztják a 10, 20, vagy 40 Mhz-es vivőt. Szokás COFDM-nek nevezni. A COFDM-nél 48 subvivő az adatoknak, és a maradék 4 subvivő pedig a szinkronizáció számára van lefoglalva.

802.11.ac Ennek a szabványnak a fejlesztése még folyamatban van, de jelentős változásokkal kecsegtet. A 802.11n-es legújabb vezeték nélküli hálózati szabványhoz képest háromszoros sebességnövekedést ígérnek a fejlesztők, így ezzel elméletben elérve a Gigabites sebesség határt. Ez a sebesség már versenyképes a vezetékes hálózatokkal is. Elémletben egy 3 antennás eszköznél a sebesség 860 Mbit/s és 1.3 Gbit/s között mozoghat majd. Míg a 802.11n szabvány a 2.4 és 5 GHz-es frekvenciatartományt egyaránt használja , a 802.11.ac szabvány csak az 5 GHz-es frekvenciatartományt fogja. Ez azért fontos mert így az interferenciát, amit az otthon használt berendezések keltenek, pl: mikro, kapunyitó stb.., jelentős mértékben csökkenti. Bár ez a sávszélesség rovására megy, de zavartalanabb kommunikációt érhetünk el és nagyobb átviteli sebességet.

26


A 12. ábrán az eddig átnézett szabványokat láthatjuk a 802.11ac kivételével és azoknak számos paraméterét, mint az átviteli távolságot, frekvenciát, csatornák számát hasonlíthatjuk össze.

12.ábra: IEEE 802.11a, 802.11b, 802.11g, 802.11n szabványok

Titkosítások WiFi használata esetén, nem nyújt elég védelmet, ha csak azt korlátozzuk, hogy egy kliens csatlakozni tudjon a hálózatunkhoz. Egy elég erős antennával rendelkező gép, amelyik küldeni is képes az irányunkba, akár komoly károkat is okozhat, használhatja az erőforrásainkat. Mivel a sugárzott rádiófrekvenciás jelek messze elérnek, ezért bárki lehallgathatja őket, akár fontos adatok és kódok is a birtokába kerülhetnek, az ilyen lehallgatások során. Ennek a kivédése érdekében titkosítják a WiFi által sugárzott jeleket. Az alábbiakban bemutatok pár módszert amelyiket a WiFi titkosítására használnak, hogy megvédjék a hálózatunkat az idegen kezek elől.

WEP Az első vezeték nélküli hálózatoknál használt titkosítási módszer a WEP (Wired Equivalent Privacy) volt. Nevéből adódóan a vezetékessel egyenértékű titkosítási 27


módszer. A WEP-nél az adatfolyamot az RC4-es titkosítóval titkosítják, a hibaellenőrzésre pedig a CRC-32 ellenőrző összeget használják. 40 bites kulcsból áll az alap WEP titkosítás, mely még kiegészül egy 24 bites IV-vel (Initialization Vectorral), ezzel megalkotva az RC4 Traffic adattovábbító kulcsát. A 40 bites megoldás nem tűnt elég biztonságosnak néhány esetben, ezért kifejlesztették a 128 bitből álló WEP kulcsot. A 128 bitből álló kulcsot egy 26hex karakterből álló String-et jelentett, melyből minden karakterre jutott 4 bit. Az így kapott 104 bitet hozzáadva az IV-t megkapjuk a 128 bitből álló WEP kulcsot. Léteznek 256 bites WEP kulcsot alkalmazó rendszerek is, bár ez nem feltétlenül jó megoldás, mert a nagyobb kulcs több adatátvitellel jár és itt előfordulhatnak IV ütközések és nem védi a nagyobb WEP kulcs a már megváltoztatott csomagokat. Manapság már nem igazán használatos ez a titkosítási módszer, mivel sok a gyengesége, és az interneten nem egy programot találni, ahol pár titkosított csomag lehallgatása során egyszerűen visszafejthető a hálózat jelszava.

WPA,WPA2 Mivel a WEP titkosítás nem mutatkozott elég biztonságosnak a vezeték nélküli hálózatok számára, mert több hibát és hiányosságot is tartalmazott a fejlesztők szerint, ezért új protokollt hoztak létre a Wifi Protected Access-t , rövidítve WPA-t. Ez a titkosítás az IEEE 802.11i szabvány fontosabb szabályát tartalmazza. Kifejlesztése során odafigyeltek, hogy az összes vezeték nélküli hálózati kártyával együttműködjön, de az első generációs AP-oknál nem minden esetben működik. Kifejlesztették a WPA2-őt is, ami már a szabvány összes szabályát tartalmazza. A titkosítás itt is RC4-el valósul meg, amire 128 bites kulcsot használ. Ez kiegészül még egy 48 bites Initialization Vectorral. A legfontosabb újítás a TKIP bevezetése volt, ami dinamikusan változtatja a kulcsokat, így védelmet nyújtva a kulcs visszafejtés ellen, mint amit a WEPnél említettem. Továbbá a CRC helyett, mivel ezt a WEP kulcs ismerete nélkül is módosítani lehetett, bevezették a jóval biztonságosabb üzenet sértetlenségi kódot a MIC-et, amely egy Michael algoritmussal valósul meg. Ez egy keretszámlálót tartalmaz, a replay attack támadások kivédése ellen. a további biztonságossá tétel érdekében kapott még a WPA egy új AES algoritmust, a CCMP-t.

28


4. Mérések Méréshez használt eszközök Az alábbiakban bemutatom a műsorszórásra használt különbező eszközöket, valamint vevőkészülékeket, amik segítségével a mérések el lettek végezve.

IPTV szerver (CW4851) A műsorszórásnál a CableWorld IPTV szerverét(CW4851) használtuk(13. ábra).

13. ábra: CW4851 IPTV Szerver A készülék főbb jellemzői: 

Felfűzhető ASI bemenetek, 100 Mbit/s sebességű Ethernet kimenet



Multicast, unicast, broadcast címzési lehetőség IPv4 környezetben



Beállítás és programozás külső PC-vel Windows környezetben, üzemelés számítógép nélkül



Széles tartományban rugalmasan változó kimeneti adatsebesség



PID szűrési- és újratérképezési lehetőség (PID Filtering, PID Remapping)



PAT, PMT, SDT és NIT táblakezelés, felhasználói packetek beillesztésének lehetősége



19”-os 1 modul magas készülék, alacsony fogyasztás, folyamatos üzemmód

Az IP TV szolgáltatás adatai 

Kimeneti adatformátum: UDP/IP



Protocol: IPv4 szerint



Adattartalom: 7 × 188 bájt méretű szinkronizált packet vagy CW-Net formátum



Adatsebesség: 0 ... 56 Mbit/s, az elementary streamek adatsebességének összege 29




Ethernet kimenet: REALTEK RTL8201



Üzemmód: 100 Mbit/s (full duplex)



A csatlakozó típusa: RJ45



Üzemmódok: o Send TS to Me o Send TS to IP Address o Send TS to Broadcast o Send TS to Multicast

Switch - D-Link DGS-3024

14. ábra: D-Link DGS-3024 A mérések során a D-Link DGS 3024 switch-et használtuk(14.ábra). Ez egy teljesen menedzselhető Layer2 Gigabit switch. Nagy adatforgalmú vállalatok számára tervezett switch. 24 darab 10/100/1000Mbit sodort érpárú porttal rendelkezik Gigabit sebességű adatátvitelt biztosítva. Ezek között nem csupán két, hanem négy Combo port található, melyek egy Mini-GBIC modul csatlakoztatásával átalakíthatók LX vagy SX Gigabit üvegszálas portokká. Akár 4 10/100/1000Mbit port egy trunk-ba foglalásával 8 Gbit sávszélesség érhető el (Full-Duplex módban), és a kaszkádolásnak köszönhetően a bővítés lehetősége is biztosított. Minden port képes egyidőben teljes sebességgel csak küldeni illetve fogadni adatot az úgynevezett ''non-blocking'' módban. Ennek köszönhetően rendkívül gyors adatátvitel érhető el. A gyors adatátvitel másik aspektusa a Quality-ofService/ Class-of-Service mechanizmusok működése. A DGS-3024 áthaladás-kontroll (802.1x, port-alapú) és prioritási sor (802.1p) funkciója célirányos és megszakítás nélküli adatátvitelt tesz lehetővé.

AP - Mikrotik 433 AH routerboard 30


A mérések során használt AP a Mikrotik 433 AH routerboard volt (15. ábra). Három 10/100 Mit/s-es Ethernet portot és a három miniPCI kártyahelyet és egy MicroSD helyet tartalmaz. 680MHz-es Atheros processzorral ellátott. A microSD kártyával bővíthető a eszköz tárhelye.

15. ábra

Antenna - Airmax 19dBi 5GHz Antennának egy 5 GHz, 120°-os, 802.11n szabványos, 2x2 MIMO technológiával és Rocket M5 csatlakozási lehetőséggel ellátott, 19dBi-s Ubiquinti Airmax-ot(16. ábra) használtunk.

16. ábra

Vevőeszközök - Ubiquiti SR71X, SR71 USB Vevőknek két Ubiquinti SR71-es modell lett használva (17. ábra). Két WirelessN(802.11n)-es kártya, amik802.11g, 802.11b és 802.11a módokban is egyaránt működnek. Magasabb frekvenciatartományok használata miatt magasabb átviteli sebesség érhető el az ilyen eszközökkel. A MIMO technológiát használja.

17. ábra: Ubiquiti SR71X, SR71 USB 31


Mérési helyszínek A méréseket Miskolc - Egyetemváros területén végeztük el különböző helyszíneken és beállításokkal. Összesen öt darab mérési helyszínt használtunk, amik a 18. ábrán sárga csillaggal vannak jelölve. Különböző távolságokról , takarásban lévő, és nyílt terepen is végeztünk méréseket.

18. ábra: Mérési helyszínek Az stream továbbításához használt antennát a Miskolci Egyetem Bölcsésztudományi Kar épületének tetőterében helyeztük el, 15 méteres magasságban, amit a 18. ábrán piros csillaggal jelölve látunk. A különböző mérési pontokat rövidebben összefoglalom. 1. helyszín: A turbinánál, az antennától 170 méter távolságra helyezkedik el, nyílt terepen, nem takarja semmi. 2. helyszín A turbina mögött a fák takarásában lévő mérési pont. 200 méter a mérési pont távolsága az antennához képest. 3. helyszín Az A/1-es épületben lévő mérési pont, melynek rálátása van az antennára és attól 380 méter távolságra helyezkedik el, 5 méteres magasságban. 32


4. helyszín Az negyedik helyszín helyezkedik el a legtávolabb, körülbelül 500 méterre az antennától. Ez a mérési pont az E/7-es épület tetején helyezkedik el, ahol szintén nyílt rálátása van az antennára. Az antenna és az E/7 emelet közötti szint eltérés kb 10 méter, az antenna középpontja a legfelső emeletre irányítva. 5. helyszín Az utolsó helyszín közvetlen az antennát elhelyezett épületen belül található, melyet több beton fal is elválaszt. Ez körülbelül 50-60 centiméter beton-t jelent mely egy újabb akadály, de mégis már jellegű mint az eddigiek.

Méréshez használt programok A mérések során különböző programokat használtunk, melyek mindegyike más célt szolgált. Az alábbiakban ezeket a programokat mutatnám be röviden. VLC Player: Médialejátszó melyet a stream rögzítésére használtunk. A nyers adatfolyam lett vele rögzítve, a program által javított és az eredeti is. Inssider: Az inssider programmal egyszerűen ki lehet listázni a közeli wifi hálózatok paramétereit, például csatorna használat, frekvencia . Airmagnet: Az inssiderhez hasonló, de tudásában jóval fejlettebb analizáló program. Az alap beállításoktól kezdve az interferencia méréséig mindenre képes, jól használható program. VStream: Ez a program végzi a felvett stream analizálását, tehát ez már nem az átviteli közeggel, hanem magával a stream-el és annak kiértékelésével foglalkozik. Mivel a program validálásához ez a program szolgáltatja a legfontosabb eredményeket, ezért ennek a leírását bővebben is részletezem.

VStream: A VStream egy nagyon sokoldalú program az IPTV minőségének a vizsgálatára. Sok információt ad a beállításokról és a minőségi értékekről, melyek közül a számomra legfontosabbat emelném ki, amely a MOS (Mean Opinion Score) névre hallgat. MOS: A MOS egyfajta video elemzést végez, ami a stream több rétegének csomagjait vizsgálja a fogadó végpontoknál. A MOS normalizált módon nyújt objektív elemzéseket a video stream mai körülmények közötti megfelelésének, különböző becslési algoritmusok használatának segítségével, amik magukba foglalják az emberi látás és hallás rendszer , tehát különböző audio-vizuális vizsgálatokat. Az ITU-T P.800 –ban definiáltak egy 1-5-ig terjedő skálát a MOS számára (19. ábra), ami egységesíti a különböző átviteli minőséget vizsgáló programok számára ezt az értéket. A video minőségi értékeinek vizsgálatához manapság ez a legjobban használt módszer. 33


Mean Opinion Score (MOS) Typical Speech Codec and MOS MOS

Quality

Codec

Data Rate (kbits/sec)

MOS

5

Excellent

G.711

64

4.3

4

Good

G.729

8

3.92

3

Fair

G.729a

8

3.7

2

Poor

G.726

32

3.8

1

Bad

AMR

12.2

4.14

19.ábra: MOS értékek és kódoláshoz tartozó értékek Tehát mint látjuk az 1-től 5-ig terjedő skálán az 1-es a legrosszabb az 5-ös a legjobb vételi minőség, valamint láthatjuk még különböző beszédi kódekek maximum MOS értékét is. A MOS értéknek 2 fajtáját is megkülönbözteti a program és az összegzésben ezeknek egy átlagát adja vissza audióval bővítve, ami a fő viszonyítási alapomat képviseli. Sajnos a VStream által használt pontos algoritmusok listáját nem tették közzé. Abszolút MOS-Video átlaga: Az abszolút MOSV egy becslési minőségi pontszámot ad vissza, amely figyelembe veszi a kódolási kvantálási szinteket, az IP károsodásait, mint például a csomagveszteségek, ezen kívül a GOP szerkezetet, a video tartalmakat, a veszteségek eredményességét az elrejtett metódusoknak. Nem veszi figyelembe a képméretet, a felbontást, a frame rátát és hogy váltott soros vagy progresszív a szkennelési mód. Viszonylagos MOS-Video átlaga: A viszonylagos MOSV teljes egészében megegyezik az Abszolút MOSV-vel, az összes tényezőjét ugyanúgy vizsgálja, annyi különbséggel, hogy itt már hatással van a képméret, felbontás, frame ráta és a szkennelési mód is. EPSNR(Edge Peak Signal to Noise Ratio): Az EPSNR az éleknél lévő jel-zaj viszonyt vizsgálja. Azon a tényen alapszik, hogy az emberek nagyon érzékenyek az élek körüli degradációkra, mint amikor az élek homályosak. Emellett sok tömörítési algoritmus okozhat ilyen mellékhatásokat az éleknél. Az EPSNR az ilyen eredetű jel-zaj viszonyokra ad értékelést. Ez az érték a minőség romlásával csökken.

Mérési konfigurációk Nem csak a mérési helyszíneket változtattuk, hanem a mérés során különböző konfigurációkat és különböző időjárási körülményeket is mértünk. Az IPTV szerver által kettő csatorna került továbbításra aminek átviteli sebessége 12 MBps körüli volt. Ezen a mérések folyamán nem változtattunk. 34


Időjárási körülmények: Kétfajta időjárási körülmény között mértünk, amelyek a következőek: 

tiszta-napos idő



esős-borús idő

A Mikrotik 433 AH routerboard nevű Acces Point volt még aminek a konfigurációján változtatásokat eszközöltünk. Itt a különböző frekvenciákat , Wifi szabványokat és az ezekhez tartozó sokféle beállítást lehet módosítani. Az 5Ghz-es frekvencián nem változtattunk, hogy az interferenciát a legjobban elkerüljük. Az alábbiakban felsorolom a használt konfigurációkat: 5 GHz a/g szabványt használva, az átviteli sebességeket módosítottuk a mérés során. 1. 12/18/24 Mbps

napos/tiszta

2. 12/18/24 Mbps

esős/borús

3. 24/36/48/54 Mpbs

napos/tiszta

4. 24/36/48/54 Mbps

esős/borús

5. 36/48/54 Mbps

napos/tiszta

6. 36/48/54 Mbps

esős/borús

5GHz only N szabványt használva az MCS értékeket állítottuk. 7. HT MCS 1-2

napos/tiszta

8. HT MCS 1-2

esős/borús

9. HT MCS 3-4

napos/tiszta

10. HT MCS 3-4

esős/borús

11. HT MCS 5-6-7

napos/tiszta

12. HT MCS 5-6-7

esős/borús

MCS(Modulation and Coding Scheme): A modulációs és kódolási séma különböző indexű elemekből áll. Az egyes indexek meg tudják határozni egy kívánt Wifi kapcsolat átviteli sebességét. Ezen kívül meghatározhatjuk vele az antennák számát, hogy melyik modulációs típusokat használja és a kódolási arányt, ha lehetséges. A valóságban az MCSk függnek a hardver tervezéstől, a helyi interferenciáktól. Ha egy Wifi kapcsolat nem tartható fent a sok CRC hibából adódóan, akkor az MCS értékét csökkenteni lehet, hogy a hiba arány kisebb legyen. Ezt egy másik elnézőbb modulációnak vagy kódolási aránynak tudható be, de a hátránya hogy az átviteli sebesség rovására is mehet. Az alábbiakban (1. táblázat) az MCS indexek és hozzájuk tartozó beállítások láthatók.

35


1. táblázat : MCS értékek Tehát mint az ábrából láthatjuk, a méréseket a QPSK a 16-QAM és 64-QAM modulációs egységekre bontva végeztük el az MCS beállítások megfelelő módosításával. Ezt mind az 5GHz-es only N szabvány segítségével. Valamint az 5GHz-es a/g szabvány átviteli sebességének különböző variációival hajtottunk végre méréseket.

36


Mérési eredmények A mérési eredmények közül csak az A/V MOS átlagát emeltem ki és foglaltam táblázatba, mivel ez egy mindent átfogó értéket ad a stream minőségéről, de a mellékletben a VStream program által készített teljes riportot is meg lehet tekinteni. Az alábbi táblázat (2. táblázat), különböző konfigurációs beállítás és időjárási körülmény között foglalja magában az 5 mérési helyszínen kapott eredményeket.

A/V MOS eredmények Mérési konfigurációk 5GHz 12-18-24 napos 5GHz 12-18-24 borús 5GHz 24-36-48-54 napos 5GHz 24-36-48-54 borús 5GHz 36-48-54 napos 5GHz 36-48-54 borús 5GHz only N MCS 1-2 napos 5GHz only N MCS 1-2 borús 5GHz only N MCS 3-4 napos 5GHz only N MCS 3-4 borús 5GHz only N MCS 5-6-7 napos 5GHz only N MCS 5-6-7 borús

1. Turbina

2. Turbina mögött

3,23 3,46 3,05 3,55 2,13 1,79 3,39 3,72 3,1 3,5 3,51 3,54

3,23 3,21 3,14 3,02 2,9 2,33 3,36 3,28 3,4 3,58 3,45 3,61

3. 4. A1 töve E7 emelet 3,2 3,12 3,19 2,87 3,18 2,23 3,56 2,88 3,23 3,26 3,36 3,63

3,27 3,41 3,04 3,46 3,18 2,08 3,32 2,91 3,09 3,29 3,36 3,18

5. Fal 3,37 3,36 3,5 3,24 2,2 2,11 3,35 3,47 3,54 3,53 3,61 3,41

2. táblázat: A/V MOS eredmények

Az eredményekből látható hogy egy beállítás kivételével mindenhol megfelelő minőségű eredmények jöttek ki, a legszembetűnőbb változás az 5GHz a/g szabvány 36-54 mbps átviteli sebességénél jött elő. A mérések során igyekeztünk elmenni az IPTV-s továbbítás végletéig, ami jelen esetben ez a 36-54 mbps-ig terjedő továbbítás volt. Az itt kapott mérési eredmények jelentősen rosszabbak, sőt jelen esetben az adás élvezhetetlenné válik. Tehát az 5GHz a/g 36-54mbps konfiguráció nem alkalmas IPTV-s műsorszórásra a mi esetünkben. Az 5 mérési hely közül az 1. Turbina és 5. Fal mérési helyeken kaptuk a legjobb eredményeket, bármilyen beállítást használtuk. Ezután következett a minőség szempontjából a 2. Turbina mögötti helyszín, majd a 4. E7 emelet, és végül az 3. A1 töve, az utolsó helyen, ahol a leggyengébb volt a stream vételi minősége. Mint a táblázatból láthatjuk a mérések során közel egyforma eredményeket kaptunk. A legjobb konfigurációnak az 5GHz only N MCS 5-6-7 mutatkozott, ahol mind a napos

37


mind a borús időben viszonylag jobb eredményeket kaptunk. Ez a beállítás a 64-QAM modulációt használja 2/3 3/4 5/6 kódolási rátákkal. Az IFramer program által mért eredményeket a validálás című főpontban vetem össze az itt bemutatott eredményekkel.

38


5. A vezeték nélküli IPTV-s adatfolyamok javítására képes szoftver folytatása Szakdolgozatom ezen részében, a vezeték nélküli IPTV-s adatfolyamok javítására képes, Porcs Milán Lajos által megírt szoftvert mutatom be, ami az Iframer nevet kapta. Valamint az általam ehhez a szoftverhez hozzátett fejlesztéseket, javításokat. Mielőtt még belekezdek ezek tárgyalásába, röviden bemutatom a Java programozási nyelvet, amiben a program íródott.

5.1. Java nyelv rövid ismertetése Fontosnak tartom a használt programozási nyelv ismertetését, mert ez nagyban segíti a program működésének megértését. A következőkben csak a megírt Iframer programban használt fontosabb eszközöket mutatnám be a Java nyelvből, a teljesség igénye nélkül. A Java nyelv egyik legfontosabb tulajdonsága a platform függetlenség, amit virtuális gép segítségével valósít meg. Ez a virtuális gép fordítja le a java forráskódját az éppen adott hardver gépi kódjára. Osztály: Egy osztály adatokból és módszerekből épül fel és az objektumok közös tulajdonságait definiálja. Tulajdonképpen egy típust határoz meg. Objektum: Adatokat tárol és műveleteket végez. Van saját állapota, és műveletei és futásidőben azonosítható. Beágyazott osztály: Teljes egészében megegyezik az Osztály fogalmával, csak annyi különbséggel, hogy ez az osztály nem külön forrásfájlban, hanem egy másik osztály forrásfájljában beágyazva található, ezért a beágyazó osztály összes adatával és módszerével is rendelkezni tud. Módosítók: A Javaban a módosítók segítségével különböző hozzáférési kategóriákat adhatunk meg. Három módosítót különböztetünk meg, a public , private és a protected. A public bármelyik osztály által bármelyik csomagból elérhető. A private az csak az adott osztályban elérhető. A protected pedig a leszármazott osztályokra is kibővíti az elérhetőséget. Van még egy eset, amikor nincs módosító, ilyenkor az adott csomagban lévő összes osztályból elérhető az adott adattag vagy metódus. Szálkezelés: A Java programnyelvben nem csak egy szálon, akár több szálon futó programok is létrehozhatóak, ezek a szálak párhuzamosan futnak egymás mellett. Szálakat a Javaban kétféleképpen hozhatunk létre, az egyikmód a Runnable interfész implementálása, a másik mód pedig öröklés a Thread oszályból. Akármelyik módszert válasszuk mindkettőnél a Run metódusban szereplő kód fog végrehajtódni. Az ily módon létrehozott szálak még nem futnak, futásukat a Start() metódussal lehet elindítani, amit a Thread osztályból örököl.

39


Interfész: a Java interfész az osztály olyan elemeit tartalmazza amik a külvilág számára fontosak. Általában metódusokból áll, de lehetnek adat részei is. A metódusok törzse nincs definiálva, azok csak az implementálásnál lesznek megírva. Többszörös interfész öröklődés is megvalósítható. Try-With-Resources: Ez az állomány biztosítja, hogy az összes erőforrás le legyen zárva a program végén. Ezt minden kapcsolat felépítésnél fel van használva a programban.

5.2. Iframer program ismertetése A Porcs Milán Lajos által megírt Iframer program az IPTV adás-vételi minőségének vezeték nélküli hálózaton való javítására szolgáló szoftver. Mivel az IPTV az UDP protokollt használja szállítási rétegként, aminél nincs kapcsolat felépítés, ezért előfordulhat, hogy a csomagok nem érkeznek meg, a nyugtázás hiánya miatt, vagy a beérkezési sorrend is felborulhat. Valamint a vezeték nélküli hálózatoknál a jelátvitel minőségét és a jelerősséget rengeteg dolog befolyásolja, például tereptárgyak, időjárási körülmények. Az Iframer program ezen hibákból adódó veszteséget hivatott pótolni. Mivel az I képek nagyon fontosak, mert ezek egy teljes képet tartalmaznak és belőlük származtathatók a P és B képek ezért a program ezen képkeretek pótlására lett valamint a P képek pótlására lett megírva. Mivel ezek pótlására idő kell, átmenetileg egy pufferben van tárolva a stream és ott történik meg a javítás. A továbbiakban bemutatom az Iframer program felépítését osztályait, interfészét, hogy átláthatóbb képet kapjunk a program működéséről.

IdefaultProperties Az IdefaultProperties interfész tulajdonképpen minden osztály használja. A többszörös interfész öröklődés miatt nagyon fontos a programban. A ControlPanel osztálynál a Jframe leszármaztatása miatt már nem lett volna lehetőség leszármaztatni, így interfészként ez a probléma nem lép fel. Globálisan használt adattagokat alkalmaz, amiket szinte minden osztály használ. Az adattagok a „public static final” módosítót kapták, így nem felüldefiniálhatók, statikusak és bármely csomag bármely osztályából elérhetőek. A kapcsolat felépítéshez, csomagméretekhez, az MPEG-2nél használt különböző startkódokhoz és egyéb fontos adatokhoz tartalmaz adattagokat.

CommonMethods A CommonMethods osztály több osztály által közösen használt metódusoknak ad helyet. Ezek mind nyilvánosak, public módosítójúak, így szabadon hozzáférhetők. A Transport Stream csomagokhoz tartalmaz különböző műveleteket, például, hogy tartalmaz-e start kódot az adott csomag, vagy van-e benne kép kezdetét jelző kód, valamint egy metódus a képkeret típusát is visszaadja. Az időbélyeg kinyeréséhez tartozó metódus is itt kapott helyet, valamint a GOP Start kódot vizsgáló metódus is. Tartalmaz 40


még egy metódust amellyel ByteBuffereket különböző részekre lehet szétszedni, valamint egy olyan metódust, ami minden csomaghoz egy azonosítót készít. Az üzenetküldéshez szükséges metódus is itt kapott helyet.

KeyFrameTable A KeyFrameTable osztály az egyértelműség kedvéért egy képkeret típusát jelenti. Ha a program egy képkeret kezdő jelzést talál, akkor létrehoz egy táblát és abban tárolja az adott csomagot, valamint a generált azonosítóját. Ez a két adat kap helyet a konstruktorában, valamint még a tábla azonosítója is. Különböző getter és setter metódusokat tartalmaz, melyekkel az azonosítók és a csomagok taralma beállítható és kinyerhető. Ezeknek a beállítása történhet index-el is. A méretét visszaadó és az összes adatot visszaadó metódust is tartalmaz.

GopToGopStream A GopToGopStream osztály tulajdonképpen egy Group of Picture objektumot hivatott jelképezni. Helyet kapott benne egy időbélyeg, az adott GOP által tartalmazott I-Tábla, valamint P-Tábla, és a további adatoknak egy külön ByteBuffer. Az adatokhoz itt is külön getter és setter metódusokat tartalmaz. Az integrálási függvény, amiben a hiányos képkereteket javítja az is ebben az osztályban kapott helyet, valamint még egy fontos függvény, ami a pufferben tárolt, javított adatokból előállítja a lejátszandó streamet.

StreamBuffer A SteamBuffer osztály valósítja meg azt az átmeneti tárolót amelyben helyet kap a stream a javítás időtartamára, tehát ez a puffer osztálya. LRU gyorsító tár elvet valósít meg. A legrégebben bekerült elem ürül ki a pufferből és egyben lejátszásra is kerül. Beállítható továbbá a puffer mérete is. A gyorsítótár kezelésére való metódusoknak egy külön beágyazott osztály került definiálásra a StreamBuffer osztályon belül, a gopBuffer osztály. Csak a szükséges cache kerül deklarálásra benne egyetlen adattagként. Olyan metódusok kerültek bele, amivel a cache-be adatokat írhatunk vagy kérdezhetünk le. Például itt kerül bele a pufferbe a már általunk részekre bontott stream, például gop start kódja, I és P framek start kódja valamint ezeknek a további csomagjai. Nagyon fontos, hogy itt kerülnek meghívásra a synchronized módosítóval ellátva a képkeretek javítására szolgáló függvények, ami azért fontos, mert így egyszerre csak egy szál módosíthatja az adott tartalmat. Két szál fut ebben az osztályban, az egyik a puffert kezeli a másik a lejátszást. A beágyazó oszátly, a StreamBuffer osztály is különböző puffer kezelő metódusokat tartalmaz, amik úgymond előkészítik az adatok a gopBuffer osztály számára és egy függvényt, ami az előkészített javított streamet a localhoston lejátszásra küldi.

ControlPanel 41


A ControlPanel osztály a grafikus felület megjelenítéséért felelős. Különböző beállítási lehetőségeket nyújt, attól függően, hogy a szerver, vagy a kliens részét akarjuk elindítani a programnak. Tehát az Iframer main metódusa is ebben az osztályban található. Külön szálat kapott a vezérléshez. Az alapértelmezett adatokat, az IdefaultProperties interfészből nyeri ki. Csoportcímet és a programhoz szükséges különböző portokat állíthatjuk itt be, valamint a pufferben tárolt GOP-ok számát is megadhatjuk a kliensnél.

KeyFrameTableServer A KeyFrameTableServer osztály több szálon fut egyszerre, az egyik figyeli és feldolgozza a kapott streamet. Lehetőség van itt egy külön porton a stream továbbítására is. Egy másik szál a beérkező I-request-eket, azaz I kéréseket vizsgálja, és küldi vissza a kért csomagokat a kliensnek. Ez már a P-framek kérését is tartalmazza. Külön szál van még az azonosítók szétküldésére. A szerver a feldolgozás során menti a csomag azonosítókat és azokat küldi a kliensnek, és a kliens a beérkezett csomag azonosítóit ezekkel összehasonlítva már el tudja dönteni, hogy van-e hiányzó csomag. A programban az I és a P táblák azonosítói is küldésre kerülnek, ezek mind külön-külön szálon. A feldolgozás, táblák szórása, a kérések feldolgozása és a kért adatok újraküldése mind különböző porton történik és ezeknek a szálai beágyazott osztályokban helyezkednek el.

KeyFrameTableReciever A KeyFrameTable Reciever osztály is több szálon fut egyszerre, figyeli és feldolgozza a beérkező streamet, amit egyben el is ment a pufferbe. Az egyik szálon figyeli a beérkező I és P táblaazonosítókat az ehhez tartozó portján és összehasonlítja azokat, a saját maga által tároltakkal, és hiányzó adatok esetén kérést küld a megfelelő porton a kliensnek. Külön szálon figyeli még a kért csomagokat és megérkezés esetén fel is dolgozza, pótolja azokat. Itt is különböző portokon történik a különböző információk átadása. A feldolgozást, javítást és kérést végző szálak mind külön beágyazott osztályban szerepelnek a programban.

5.3. A programon végzett fejlesztések Az alábbiakban osztályonként végighaladva az Iframer programon, bemutatom az általam hozzátett módosításokat és elmagyaráznám azok működését.

IdefaultProperties A globális adatokat tartalmazó interfész a következő adattagokkal bővült: int B_FRAMES_PER_GOP = 50; Egy Group of Pictures álltal tartalmazott GOP-ban található B framek maximum számát adja meg. byte B_FRAME_TABLE_FLAG = 3; 42


Egy csomagban, amelyik tartalmaz képkeretet, a kép kezdetét jelző bájt után a kép fajtájának a jelzése következik. Az 3-es jelzés az B kép kezdetét adja meg. byte SLICE_START_LOW = 0b00000001; byte SLICE_START_HIGH = (byte) 127; A start kód után a SLICE-ot egy adott intervallumon belüli azonosítóval adják meg, ezeknek a határát jelenti e két adattag. byte SLICE_START_SIGNED_LOW = (byte) 128; byte SLICE_START_SIGNED_HIGH = (byte) 175; Mivel a Java-ban nincs UNSIGNED változó, amire a SLICE-ok vizsgálatánál szükségünk lenne, ezért külön intervallumot kellett létrehozni a 127 feletti értékű byte típusú számok esetén. int B_FRAME_CODE = 3; Lényegében ugyanaz, mint az I_FRAME_TABLE_FLAG, de a programkód könnyebb átláthatósága kedvéért és a külön típusa miatt kapott helyet a programban. int P_FRAMES_PER_GOP = 50; Ennek az adattagnak a jelentése is megváltozott, most már a maximum P framek számát jelenti egy GOP-ban.

CommonMethods A közösen használt függvények osztályában is történtek változások. public int isIframe(ByteBuffer packet) Működése továbbra is a régi maradt, hogy egy beérkező ByteBuffer csomagról megállapítja, hogy tartalmaz-e képkeretet. De annyiban különbözik, hogy nem csak I framekkel tér vissza, hanem adott esetben már a B és a P framekkel is, ezzel segítve, hogy meg tudjuk állapítani a kép típusát. public boolean isSliceStart(ByteBuffer packet) Egy új metódus. A beérkező ByteBuffer csomagról megállípítja, hogy van-e benne start kód és ha van akkor SLICE kezdetét jelöli-e.

GopToGopStream A fejlesztés során a legtöbb változás a GopToGopStream osztállyal történt, aminek az új vagy megváltoztatott metódusait vagy adattagjait a következőkben mutatnám be. private ByteBuffer data; Az egyéb adatokat tároló ByteBuffer már nem tömb formájában kapott helyet a programban, hanem csak egy sima ByteBuffer adattagként. Ezek kihatással lettek a getter 43


és setter metódusaira is, amik szintén módosításra kerültek a programban. Ezek a következőek: -public ByteBuffer getOtherData() -public void addOtherData(ByteBuffer otherData) Az eddigi Iframer program egy csatornát tudott javítani, egy adott GOP felépítés mellett, de mivel különböző csatornák, különböző GOP struktúrákat is használhatnak ezért, jobbnak láttam az adott stream feldolgozásánál elemezni az adott GOP struktúráját és ezt letárolva felhasználni. private ArrayList GOP_FRAMES_STRUCTURE; Ez az adattag a stream feldolgozásánál az aktuális GOP struktúráját kapja meg egy Integer listán. A különböző struktúrák miatt találtam jónak a lista alkalmazását egy fix szám helyett. Két különböző érték szerepelhet a listában, az egyik a képkeret típusa, a másik pedig a GOP-ban betöltött sorszáma. public GopToGopStream(ByteBuffer gopTimeStamp) Az újítások miatt az osztály konstruktora se maradhatott változatlan, amely kibővült még egy B-táblával (bFrames), a GOP struktúra azonosítására használt adattaggal (GOP_FRAMES_STRUCTURE), valamit a egyéb adatok tárolója is módosult (data). public int addGOP_FRAME_STRUCTURE(int frametype,int id) A GOP struktúra beállító metódusa, mely megkapja paraméterül a képkeret típusát, valamint a képkeret GOP-ban betöltött sorrendjének a helyét és ezeket hozzáfűzi a listához. public void setGopsIFrame(KeyFrameTable gopsIFrame) public void setGopsPFrame(KeyFrameTable gopsPFrame) Ez a két setter metódus, ami az I és P keretek hozzáadására szolgál bővült az addGOP_FRAME_STRUCTURE metódussal. Tehát amikor a feldolgozásnál a beérkező keretek letárolódnak, akkor adódik hozzá a GOP struktúrához is az adott képkeret és az azonosítója. public KeyFrameTable getGopsBFrame(byte num) public KeyFrameTable getGopsBFrame() Új getter metódusok a B Framek kezelésére. public void setGopsBFrame(KeyFrameTable gopsBFrame) Szintén új metódus, ami a I és P metódusaihoz hasonlóan tartalmazza a GOP struktúra beállítását. public synchronized void integrateBFrameData(byte bFrameID,ByteBuffer packet, ByteBuffer lastCorrectRowId) 44


Új metódus. A pufferben tárolt hiányos stream javítására szolgáló függvény, ami a B Framek csomagjait javítja. Ha már az első csomag azonosítója hibás vagy nem található, akkor minden újraküldött elem bekerül az újonnan létrehozott táblába, ami majd átveszi a helyét a pufferben tárolt hiányos táblának. Ezt követően az utolsó helyes azonosító utáni csomagok kerülnek a táblába, majd kijavításra. Ha nem az első csomagtól kezdődik a pótlás, akkor először a korrekt azonosítójú csomagok kerülnek át, majd utána jön a javítás. public ByteBuffer getGopToGopData() A stream előállításához használt metóduson is történtek változások, mivel különböző GOP struktúrák használatánál már ez a megadott sorrendben történő stream összerakás nem hozna eredményt. Az előbb leírt GOP_FRAMES_STRUCTURE metódust használtam arra, hogy a beérkező adatok, framek, megfelelő sorrendben kerüljenek lejátszásra. Egy ciklusban ezen a listán végighaladva, ebből a listából nyeri ki a program mikor milyen típusú, és hányadik képkeret következik, és ez alapján állítja elő a streamet.

StreamBuffer A puffert megvalósító osztályban is történtek módosítások, helyet kaptak új metódusok. Mivel ez az osztály egy beágyazott osztályt is tartalmaz, ezért a két osztályon történt változásokat külön mutatnám be. Először nézzük meg a beágyazott osztályt.

private class GopBuffer A következőkben a GopBuffer osztály új függvényeit mutatnám be. public void keyFrameTable)

addBframeTableStart(ByteBuffer

timeStamp,

KeyFrameTable

Az aktuális GOP-nál egy új B Frame táblát definiálhatunk ennek a metódusnak a segítségével. public synchronized void addBFramePart( ByteBuffer timeStamp,ByteBuffer rowId, ByteBuffer packet) Az I Frame tábla adatainak tárolására szolgál. Szinkronizált metódus, annak érdekében, hogy a feldolgozás és a pótlás ne történhessen meg egyidőben. public synchronized void integrateBframePackets(byte bFrameNum, ByteBuffer timeStamp, ByteBuffer lastCorrectRowId,ByteBuffer data) Ez a függvény hívja meg a GopToGopStream osztályban szereplő integráló metódust, amely a B-Framek pótlását végzi. Szintén szinkronizált metódus a hibák elkerülése végett. private KeyFrameTable getGopsBtable(ByteBuffer timeStamp,byte bFrameName) A B Frame tábla lekérdezésére szolgáló metódus, ami időbélyeg és kapott B frame azonosító alapján történik. 45


private boolean hasTimeStamp(ByteBuffer ts) Ez a metódus megnézi, hogy van-e a kapott időbélyeggel rendelkező GOP a pufferben tárolt GOP-ok közt.

StreamBuffer A StreamBuffer osztályba is ugyanazok az előkészítő metódusok kerültek bele, mint a GopBuffer osztályba. Ezeknek a működését már nem mutatnám be még egyszer csak felsorolásképpen említeném: 

public

synchronized

void

addBframeStart(ByteBuffer

gopTimeStamp,

KeyFrameTable keyFrameTable, ByteBuffer packet) 

public

synchronized

void

addBframePacket(ByteBuffer

timeStamp,

ByteBuffer rowId, ByteBuffer data) 

public synchronized KeyFrameTable getBframeTable(ByteBuffer timeStamp, byte bFrameNum)



public void integrateGopBFrame(byte bFrameNum, ByteBuffer timeStamp, ByteBuffer lastCorrect,ByteBuffer data)



public synchronized boolean hasTimeStamp(ByteBuffer ts)

Két olyan metódussal is bővült ez az osztály, amelyeknek nincs megfelelője a GopBuffer osztályban, ezek e következőek. public synchronized void KeyFrameTable keyFrameTable)

addEmptyPframe(ByteBuffer

gopTimeStamp,

Ez az új metódus egy új üres P framet ad hozzá a pufferhez időbélyeg alapján, teszi ezt úgy, hogy meghívja a GopBuffer addPframeStart metódusát. public synchronized void KeyFrameTable keyFrameTable)

addEmptyBframe(ByteBuffer

gopTimeStamp,

Az előzőhöz hasonlóan egy üres B Frame tábla beszúrását végzi el a pufferbe időbélyeg alapján.

KeyFrameTableServer Ez az osztály, amely a szervert valósítja meg a programban, is bővült új elemekkel. private Thread multicastBtable; Egy új szál melynek feladata, hogy a szerver által feldolgozott B táblákat szórja a kliens felé. Ez a szál is a multicastTable szálcsoportba tartozik. private class multicastBtable implements Runnable

46


Az előbb leírt szálat ez az osztály definiálja, majd indítja el a „run” metódusát a „start” paranccsal. Az indításnál a „run”-ban szereplő multicastBframeTable() metódusnak adódik a vezérlés. Tehát egy külön szálon fut a B táblák szórása. Konstruktorában tartalmazza még az adott gop azonosítóját és mivel több B-frame van egy GOP-ban az aktuális B frame sorszámát is. private boolean isOpenBframeTable; Egy boolean típusú adattag a nyitott B táblák figyelésére. private byte currentBFrame; Ez az adattag az éppen aktuális B Frame azonosítójának a tárolására szolgál. private void listeningForIFrameRequests() Ez a metódus, amelyik a klienstől fogadja a kéréseket, a B képek kéréseinek fogadására is át lett alakítva. A sikeres csatorna megnyitás után blokkolással várakozik, és egy kérés beérkezése után egy ByteBuffer allokálódik, amiből az első byte-ból kinyerhetjük, hogy I, P vagy B frame kérése érkezett-e. private void processRecievedBFrameRequest(ByteBuffer request) Ennek az új metódusnak a feladata, hogy a klienstől kapott beérkező B framekéréseket feldolgozza. Teszi ezt úgy hogy a beérkező ByteBufferről leválasztja a fejrészt, allokálja a hiányzó adatoknak való helyet. A header egy byte Flagből , egy B tábla azonosítóból és sorszámból, az utolsó korrekt tábla azonosítóból, és a kliens azonosítóból áll. A fejrészt kivonva és elosztva az ITABLE_ROW_ID_LENGTH_IN_BYTES-al, azaz egy tábla azonosítójának a hosszával, megkapjuk a hiányzó csomagok számát, amit felhasználva egy ciklussal végigmegyünk ezeken. A ciklus a hiányzó adatokkal pótolja, majd multicast-al küldésre kerülnek. Ennek az üzenetnek a fejlécében helyezkedik el a kliens azonosítója és ez alapján döntik el a kliensek, hogy az adott csomag nekik érkezett-e vagy sem. private void processRecievedStreamDatagram(ByteBuffer byteBuffer) A beérkező stream feldolgozását végző eljárás is módosításra került a programban. Nem csak az I és P keretek, hanem a B keretek feldolgozását is elvégzi. A beérkező datagrammot 7 TS csomagra bontjuk, majd ezeket a csomagokat a CommonMethods osztály közös eljárásainak segítségével megvizsgáljuk és feldolgozzuk. Ilyen eljárások például: hasStartCode(); isStartOfGop(); isPicStart(); isIframe(). Működése a következő: először megvizsgáljuk, hogy a csomag tartalmaz-e start kódot, amennyiben igen annak a vizsgálata jön hogy az Gop kezdetét jelzi-e. Ha egy új Gop jött akkor vagy egy új táblát nyit, vagy a meglévőbe raktároz és növeli az azonosítót, de még előtte megnézi van-e nyitott B vagy P frame tábla, ha van akkor ezeket lezárja. Még a StartCode vizsgálata után azt is megnézi, hogy Képkeret következik-e. Ha igen akkor a meglévő aktuális Képkeret táblát lezárja, amennyiben nyitva van, ezután kinyeri a Frame típusát az isIframe metódussal, majd ennek egy új táblát is létrehoz a Gopban. Ha új 47


képkeret jött de az azonosítója alapján egyik képkeret típusba se illek bele, tehát nem I,P vagy B Frame, ez különböző hibák folytán előfordulhat, akkor ezekhez tartozó csomagoknak egy új B Frame táblát nyit a feldolgozáshoz. Ezen műveletek után az éppen nyitott táblákba történik az adatok feldolgozása. Ha nincs nyitott tábla akkor az adatok OtherData-ként lesznek elraktározva. private void multicastBframeTable(byte currentGopID, byte bFrameNum) Ez az eljárás Gop-onként elküldi a lezárt B framek tábláját a kliensnek. Ez alapján hasonlítja össze a kliens az ő táblájában tárolt adatok, hogy van-e hiányos csomag. Az elküldött ByteBuffer tartalmaz egy B Frame Flaget a megkülönböztetés céljából, a B Frame sorszámát, az adott Gop ID-t, az időbélyeget, valamint a összes B csomag azonosítóját. Az üzenet szintén multicast küldéssel lesz továbbítva, amire egy beállított késleltetés után kerül sor.

KeyFrameTableReciever Az alábbiakban a KeyFrameTableReciever osztályon végzett módosításokat mutatnám be. private GopToGopStream[] GopToGopStream[NUMBER_OF_GOPS];

currentGOP

=

new

A currentGOP nevű GopToGopStream típusú adattag már tömb formájában kapott helyet a programban. Ez a Gop struktúra tárolása miatt volt lényeges, hogy ne csak az aktuális Gop struktúráját lehessen tudni. private void startRecievingFrameTables() Ezen metódus feladata a szerver által küldött, ellenőrzés céljára használt I P és B táblák feldolgozása és az összehasonlító metódusok meghívása a kapott adatok alapján. Az ellenőrzés itt a B Framek vizsgálatával bővült. A metódus a sikeres csatorna megnyitás és konfigurálás után, a kapott ByteBuffer első byte-jából, ami egy Flag-et tartalmaz, hogy I, P vagy B tábla érkezett-e, kinyeri, hogy melyik tábla összehasonlító függvényét hívja meg. private void startListeningForRetransmission() Ez az eljárás a kért táblák feldolgozását végzi a programban. Itt is bővült a B-kérések figyelésével is. A szokásos csatorna megnyitás és konfigurálás után, a beérkező ByteBuffer első 8 byte-jából kinyerhető a kliens azonosítója, ami azért fontos, hogy csak az a kliens dolgozza fel a beérkező adatokat, amelyik a kérést küdte. Majd a következő byte-ból a flag értékét kapjuk meg, ami alapján meghívódik az aktuális I,P vagy B tábla javítását, integrálását előkészítő függvény, ami az itt beérkező ByteBuffert kapja meg feldolgozásra, a fejléce nélkül. private void processRecievedDatagram(ByteBuffer byteBuffer)

48


A beérkező streamet feldolgozó függvény is módosult. Már nem csak egy aktuális GOP-ot tárol, hanem egy GOP táblát, mint a szerver osztálynál. Működése szinte teljesen megegyezik a szerver osztályon belüli feldolgozó függvénnyel, csak annyi különbséggel, hogy ez a függvény a beérkező adatok alapján a puffert tölti fel. A CommonMethods osztály által definiált közös metódusokat használja a stream elemzésére. Például hasStartCode(); isStartOfGop(); isPicStart(); isIframe(). Majd a már előzőekben szerver osztálynál leírt feldolgozó eljáráshoz hasonlóan feldolgozza az adatokat. Itt viszont egy új beérkező képkeret vizsgálatánál a GOP struktúra beállítását végző függvénnyel bővült. private void comparePFrameTables(ByteBuffer recievedPTable) Ez a metódus végzi a programban a szerver által szórt P Frame táblák hasonlítását. A hiányzó csomagok azonosítóinak egy ByteBuffert hoz létre majd ezeknek a pótlására egy kérést küld a szerverek a kliens azonosítójával ellátva. Ha már a legelső azonosító is hiányos akkor negatív azonosítót tárol, más esetekben pedig a előző csomag azonosítóját. Ez a metódus annyiban változott, hogy megvizsgálja, hogy van-e létező GOP az összehasonlításhoz a pufferben, ezt a StreamBuffer osztály hasTimeStamp() metódusával teszi. Ez a feldolgozás során a GOP start kód elvesztése miatti hibák áthidalására szolgál. Egy másik fontos javítás, hogy ha például nem a GOP sérült, hanem egy adott P Frame tábla és nem lett létrehozva a pufferben, akkor az eljárás nem tudja összehasonlítani azt a beérkező azonosítókkal. Ennek kiküszöbölésére „NULL” értékű P tábla esetén a StreamBuffer osztály addEmptyPframe() metódusa segítségével egy üres P Framet szúrunk be, így már a feldolgozás is sikeres lesz. private void compareBFrameTables(ByteBuffer recievedBTable) Egy új metódus, mely működésében szinte teljesen megegyezik a comparePFrameTables() metódussal, csak ez a B Frame táblák vizsgálatát végzi. Ugyanazon vizsgálatokat is tartalmazza az esetleges stream feldolgozási hibák ellen a következő metódusokkal: hasTimeStamp(); getGOP_STRUCTURE_BFRAMES_SIZE(); addEmptyBFrame(). Itt is ha az első azonosító hiányzik akkor negatív értékű azonosítót ad , ha nem akkor pedig az előző helyes azonosító értékét. private void processRecievedBFrameParts(ByteBuffer reTransData) Ez az új metódus végzi a kért B Framek integrálásának meghívását a programban. A beérkező ByteBuffer alapján kinyeri a B Frame sorszámát a GOP-ban, valamint a GOP időbélyegét és utána az utolsó korrekt azonosítót, valamint a csomagokat és ezután kerül meghívásra a StreamBuffer osztályban található integrateGopBFrame() metódus a kapott adatokkal, ami majd meghívja a GopToGopStream osztály B Framekre írt integráló függvényét.

ControlPanel és KeyFrameTable A ControlPanel osztály, ami a main metódust is tartalmazza és a grafikus felületét adja a szerver és kliens résznek a programban bővült a kliens résznél 3 CheckBox-al, amivel 49


megadhatjuk, hogy a program milyen típusú kereteket javítson. A KeyFrameTable osztály, ami egy képkeret típust jelent a programban érintetlen maradt, nem történtek benne változások.

50


6. Az elkészült szoftver validálása Mielőtt még összehasonlítom az Iframer programmal javított és a Mérések pontban leírt mérési eredményeket, először bemutatok egy kisebb a program által végzett mérést.

6.1. Különböző Framek javításának vizsgálata Mindhárom képkeret javításának, elméletben javulást kell hoznia, de egy másik érdekes dolog lehet , hogy a különböző típusú framek javítása vagy ezek kombinációinak javítása milyen eredményeket hozhat. Az Iframer programot 7 különböző variáció mellett használva végeztem el méréseket ennek a meghatározására. Plusz egy mérés a viszonyítási alapot adja.

Mérés során használt Frame javítási beállítások 1. Csak I 2. Csak P 3. Csak B 4. I és P 5. I és B 6. P és B 7. I, P és B

Mérés helyszínei Két mérési helyszínt választottam az egyik egy közeli (3. táblázat), ahol már vannak elveszett csomagok. A másik egy távoli (4.táblázat) helyszín ahol rosszabb a vétel, több a veszteség. A mérések során 5GHz-es a/g szabványú 12-54mbps átviteli sebességű beállítást használtam. Az alábbiakban táblázatba foglalva bemutatom a kapott eredményeket, valamint egy külön táblába (5. táblázat) hogy jelentettek-e javulást, és ha igen akkor milyen mértékben.

5GHz 12-54 Mbps közeli Javított keretek: Audio/Video MOS átlaga: Abszolút MOSV átlaga: Viszonylagos MOSV átlaga: EPSNR:

Nincs javított 3,53 3,8 4,07 35,5

I

P

B

IP

IB

PB

IPB

3,56 4,01 4,29 38,2

3,59 3,69 3,96 36,4

3,44 3,79 4,07 34,7

3,64 3,97 4,25 35,9

3,61 4,01 4,29 35,3

3,61 3,84 4,12 34,8

3. táblázat: közeli mérési eredmények 51

3,56 4,01 4,29 38,5


5GHz 12-54 Mbps távoli Javított keretek: Audio/Video MOS átlaga: Abszolút MOSV átlaga: Viszonylagos MOSV átlaga: EPSNR:

Nincs javított 3,09 3,2 3,47 33,1

I

P

B

IP

IB

PB

IPB

3,53 3,7 3,96 37

3,32 3,41 3,68 35,8

3,14 3,13 3,4 31,9

3,53 3,61 3,88 35,7

3,36 3,41 3,69 32,5

3,23 3,34 3,62 34,1

IB

PB

4. táblázat: távoli mérési eredmények

Átlagos javítás %-ban Javított keretek: Közeli mérés: Távoli mérés:

I 0,84% 12,46%

P

B

IP

1,67% -2,62% 3,02% 6,93% 1,59% 12,46%

2,22% 8,04%

IPB

2,22% 0,84% 4,33% 17,60%

5. táblázat: Javítás %-ban A táblázatból látható, hogy a közeli mérések során és a távoli mérések során is javulások mutatkoztak. Az EPSNR eredmények is a legtöbb esetben jobbak lettek. A közeli mérések során kisebb mértékű javulások mutatkoztak és egy esetben, a csak B frames beállítás esetén nem történt javulás. A távoli mérések jobb eredményt hoztak bár itt is szembetűnő, hogy a legrosszabb eredményt a csak B Framek javítására szolgáló konfiguráció hozta. A közeli mérések során a kevesebb veszteség oka is lehet a kisebb mértékű változás. Számítani lehetett rá, hogy a nagyobb mértékű javítások az I Frameket is javító beállításokban mutatkoznak meg. Ám összességében a legjobb, ha az összes keret vizsgálatra és javításra kerül, mert így érhető el a legjobb eredmény.

6.2. IFramer programmal mért eredmények Dolgozatom utolsó és egyben a legfontosabb részében, a mérési eredmények kiértékelését írom le. Hasonlóképpen, mint a sima IPTV-s méréseknél itt is a teljesség igénye nélkül csak a legfontosabb értéket foglaltam táblázatba, de a mellékletben a Vstream által készített teljes összegzés megtekinthető. A fő viszonyítási alapnak itt is a MOS értéket használtam, azok közül is az Audio/Video MOS átlagát mivel ez az átlag az összes fontosabb értékből tevődik össze, így ez tűnt a leglogikusabb választásnak. A táblázatban a különböző mérési beállítások és különböző időjárási körülmények mellett mutatom be az Iframer program által kapott eredményeket (6. táblázat). Az eredmények után összehasonlító táblázatban mutatom be az előbb említett A/V MOS átlag eredményeket és hogy hány százalékban jelentettek javulást a programmal való

52

3,75 4,07 4,34 38,3


mérések. Fontos megjegyezni, hogy ugyanazon körülmények között, ugyanazon időben, helyen és konfigurációval zajlott a programmal való és a program nélküli mérés is.

A/V MOS eredmények Iframerrel Mérési konfigurációk 5GHz 12-18-24 napos 5GHz 12-18-24 borús 5GHz 24-36-48-54 napos 5GHz 24-36-48-54 borús 5GHz 36-48-54 napos 5GHz 36-48-54 borús 5GHz only N MCS 1-2 napos 5GHz only N MCS 1-2 borús 5GHz only N MCS 3-4 napos 5GHz only N MCS 3-4 borús 5GHz only N MCS 5-6-7 napos 5GHz only N MCS 5-6-7 borús

1. Turbina

2. Turbina mögött

3,43 3,5 3,11 3,59 2,98 2 3,5 3,82 3,56 3,81 3,59 4

3,55 3,53 3,36 3,65 3,04 2,8 3,38 3,56 3,68 3,71 3,57 3,89

3. 4. A1 töve E7 emelet 3,3 3,5 3,2 3,01 3,88 2,75 3,63 3,25 3,46 3,43 3,38 3,79

3,48 3,55 3,44 3,57 3,24 2,58 3,39 2,93 3,46 3,36 3,51 3,46

5. Fal 3,39 3,47 3,58 3,53 2,43 2,38 3,38 3,63 3,94 3,57 3,64 3,47

6. táblázat: A/V MOS eredmények IFramerrel A táblázatból megfigyelhetjük, hogy minden esetben jobb eredményt kaptunk az Iframer program használata mellett. Az 5GHz 36-48-54 beállításnál is jobb eredmények jöttek ki, sőt a legjobb eredmények, de viszont ez a videó minőségében nem jelentett olyan változást, ami már élvezhetővé tenné a vételt, ezért ez a beállítás nem alkalmas a mi esetünkben IPTV-s műsorszórásra. Ezért a továbbiakban az összesítő táblázatban az átlag eredmények kiértékelésénél ezen beállítást nem veszem figyelembe a pontosabb eredmény meghozatala érdekében. Érdekes azonban, hogy a borús és napos idők közti különbségnél 50 százalékában jobb eredményt kaptunk a borús időnél. A mérési helyszínek minőségi értékeinek alapján való sorrendbe állítása esetén az eredmény ugyanaz, mint a program nélküli méréseknél. Átlagolva a legjobb eredmények itt is az 5GHz only N MCS 5-6-7 konfigurációnál voltak. Az alábbiakban tekintsünk meg, hogy a különböző beállítások a különböző helyszíneken hány százalékos javulást hoztak (7. táblázat).

Javítás %-ban Mérési konfigurációk 5GHz 12-18-24 napos 5GHz 12-18-24 borús 5GHz 24-36-48-54 napos 5GHz 24-36-48-54 borús 5GHz 36-48-54 napos

1. Turbina

2. Turbina mögött

6,19% 1,16% 1,97% 1,13% 39,91%

9,91% 9,97% 7,01% 20,86% 4,83%

3. 4. A1 töve E7 emelet 3,12% 12,18% 0,31% 4,88% 22,01%

6,42% 4,11% 13,16% 3,18% 1,89%

5. Fal 0,59% 3,27% 2,29% 8,95% 10,45%

53


5GHz 36-48-54 borús 5GHz only N MCS 1-2 napos 5GHz only N MCS 1-2 borús 5GHz only N MCS 3-4 napos 5GHz only N MCS 3-4 borús 5GHz only N MCS 5-6-7 napos 5GHz only N MCS 5-6-7 borús

11,73% 3,24% 2,69% 14,84% 8,86% 2,28% 12,99%

20,17% 0,60% 8,54% 8,24% 3,63% 3,48% 7,76%

23,32% 1,97% 12,85% 7,12% 5,21% 0,60% 4,41%

24,04% 2,11% 0,69% 11,97% 2,13% 4,46% 8,81%

12,80% 0,90% 4,61% 11,30% 1,13% 0,83% 1,76%

7. táblázat: Javítás %-ban A százalékos eredmények tehát mindenhol javulást mutatnak, bár a mértékük sok helyen különbözik. Ez a javított érték 0,31%-tól 20,86%ig terjed, ha a már említett 5GHz 36-48-54 beállításnál kapott eredményeket nem nézzük. Ha az összes érték átlagát nézzük, akkor 7,53%, az említett beállítás kivételével 5,61%-os eredményt kapunk. Most vizsgáljuk meg a kapott százalékos eredmények átlagát (8. táblázat) helyszíntől függetlenül. A/V MOS A/V MOS eredmények átlaga eredmények átlaga helytől függetlenül helytől függetlenül IFramer nélkül Iframerrel

Mérési konfigurációk 5GHz 12-18-24 napos 5GHz 12-18-24 borús 5GHz 24-36-48-54 napos 5GHz 24-36-48-54 borús 5GHz 36-48-54 napos 5GHz 36-48-54 borús 5GHz only N MCS 1-2 napos 5GHz only N MCS 1-2 borús 5GHz only N MCS 3-4 napos 5GHz only N MCS 3-4 borús 5GHz only N MCS 5-6-7 napos 5GHz only N MCS 5-6-7 borús

3,26 3,312 3,184 3,228 2,718 2,108 3,396 3,252 3,272 3,432 3,458 3,474

3,43 3,51 3,338 3,47 3,114 2,502 3,456 3,438 3,62 3,576 3,538 3,722

Javítás átlagértéke %-ban, helytől függetlenül 5,25% 6,14% 4,95% 7,80% 15,82% 18,41% 1,76% 5,87% 10,69% 4,19% 2,33% 7,14%

8. táblázat: Helytől független eredmények A kapott eredmények 1,76%-től 18,41%-ig terjednek, ezen táblázatból megállapítható, hogy mely beállítás mellett értük el a nagyobb javulást. Mint láthatjuk a legkevesebb változás az MCS 1-2 konfigurációnál történt, a legtöbb javítást az MCS 3-4 és MCS 5-6-7nél. A következő táblázatban (9. táblázat) tekintsük meg a beállítás független javított értékek százalékos átlagát (az 5GHz 36-48-54 beállítás kivételével, mert hiába a jó eredmény az adás élvezhetetlen).

54


1. Turbina

2. Turbina mögött

3. A1 töve

Audio/Video MOS átlaga beállítástól függetlenül:

3,405

3,328

3,23

3,233

3,438

A/V MOS átlaga programmal, beállítástól függetlenül:

3,591

3,588

3,395

3,415

3,56

Javított arány %-ban beállítástól függetlenül:

5,53%

8,00%

5,26%

5,70%

3,56%

Helyszínek:

4. E7 emelet

5. Fal

9. táblázat: Beállítástól független eredmények A különböző helyszíneken kapott eredmények szerint a legnagyobb mértékű javulás a 2. Turbina-nál volt, a legkevesebb az 5. Fal-nál. Ezen értékek 3,56%-tól, 8%-ig tehetőek, és a többi helyszínen mért eredmények 5-6% közé estek. Ezek átlagából is kiszámítható a fentebb leírt összátlag az 5,61%. A előbbi táblázatokból tehát egyértelműen kivehető, hogy az IFramer programmal való mérések jobb eredményt hoztak a stream minőségére. Bár ezek csak számszerű értékek, hogy szemléletesebb legyen képeket (20. ábra) egymás mellé téve szemléltetem, hogy ezek a számszerű értékek vizuálisan mennyi változást jelentenek a néző számára. Eredeti

Javított

20. ábra Mint ahogy a 21. ábrán is jól látható a továbbfejlesztett IFramer program kisebb és nagyobb mértékű hibák javítására is alkalmas, köszönhetően a három képkeret típus vizsgálatának és javításának. Tehát, mint láthatjuk, az adás élvezhetőségének javulásához nagymértékben hozzájárul. 55


Összefoglalás Dolgozatomban bemutattam a digitális televíziózás, IPTV alapú televíziózás alapjait, valamint az ezt alkotó adatfolyam felépítését és használt protokollokat. Említést tettem a vezeték nélküli hálózati szabványokról, amit a program is használ. Majd az IPTV-s mérések következtek, különböző beállításokkal, helyszínekkel és időjárási körülményekkel. Mindezek még az IFramer program nélkül. Ezután következett a továbbfejlesztett program leírása, részletes ismertetése. A validálásnál bemutattam egy kisebb mérést, hogy a különböző Framek javítása, mennyiben változtatja a minőséget, majd a programmal és anélkül készült mérési eredményeket, hogy mennyiben jelentett javulást a program használata. Nem szabad elfeledni, hogy az IFramer által való pótlások is az UDP protokoll segítségével jönnek létre ezért ezek végrehajtása sem garantált a program által. Még számos lehetőség van a program továbbfejlesztésére az összes képkeret vizsgálatán kívül. Ilyen például hogy a pótlás ne csak egy esélyt kapjon, így növelve a hatékonyságát. Valamint az eddigi program csak egy szerver-kliens kapcsolatra képes és a több klienssel esetleg szerverrel való kapcsolat is egy lehetőség lenne a továbbfejlesztésre.

56


Summary My thesis was about IPTV communication system with wireless transmission. The IFramer program, wich was programmed by Porcs Milán, was upgraded by myself. The program has expanded with P and B Frame requesting and repairing. It could identify the different GOP structures and be able to run with 2 channels included stream. Firstly, I was writing about the basic concept of Digital and IPTV coverage. I represented the required background information, which are nesessary to undarstand the work of the program. The next step was the measurement of IPTV, without the IFramer program. Than the results was evaluated. Other main point was the description of the upgraded IFramer program. Finally, I demonstrated the measurement of IPTV with upgreded IFramer program. The results were better in each case, than the previously measurement. But it works nicely, there are some other way to improve this program. One is that requseting should be get more chances. IFramer could be develope further, that could work with more client.

57


Irodalomjegyzék [1]

Andrew S. Tanenbaum: Számítógép-hálózatok

[2]

http://notebook.network.hu

[3]

http://www.dvbtinform.hu

[4]

Unyi Gábor: Második generációs IPTV rendszerek

[5]

http://hu.wikipedia.org

[6]

http://m.hdtvmagazine.info

[7]

http://www.hiradastechnika.hu

[8]

Gilbert Held: Understanding IPTV, New York, Auerbach Publications, 2007

[9]

WALTER FISCHER, A digitális musorszórás alapjai, Typotex Kiadó, Budapest 2005.

[10]

ISO/IEC 13818-1 (ITU-T Recommendation H.222.0): "Information technology Generic coding of moving pictures and associated audio information: Systems".

[11]

http://tv.tvnet.hu

[12]

http://www.cableworld.hu

[13]

http://www.wlan-ok.hu

[14]

http://www.erg.abdn.ac.uk

[15]

http://www.cab.u-szeged.hu/WWW/java/kiss/javaprog.html

[16]

http://www.softwareonline.hu

[17]

http://www.ixiacom.com

58

SZAKDOLGOZAT. Tóth Szabolcs F43L90

Recommend Documents