A világgazdaság helyzete, az energia-hordozókkal való takarékos gazdálkodás, a népesség-robbanás és számos kapcsolódó gond miatt az egyéni utazási formákkal szemben mindenütt keresik a tömegközlekedés színvonalának javítási lehetőségeit, ezen belül is az utasok biztonságérzetének javítási módjait.

 

A világgazdaság helyzete, az energia-hordozókkal való takarékos gazdálkodás, a népesség-robbanás és számos kapcsolódó gond miatt az egyéni utazási formákkal szemben mindenütt keresik a tömegközlekedés színvonalának javítási lehetőségeit, ezen belül is az utasok biztonságérzetének javítási módjait.

Négy Európai Uniós állam,  Franciaország, Spanyolország, Magyarország és Belgium gondozza azt a BOSS  elnevezésű projektet, ahol az  EUREKA Celtic inititiative  keretében a fenti témakörben összehangolt kutatásokat folytatnak a fedélzeti biztonság műszaki-távközlési eszközökkel való növelésére. A megoldások keresése kiterjed maguknak az utasoknak, ill. a  személyzetnek a fedélzeten való kommunikálási, kapcsolattartási lehetőségeire.

A BOSS projekt hivatalos megnevezése:   On Board Wireless Secured Video Surveillance.

A kutatásokba sikerrel kapcsolódtak be hazai szakemberek, a projekt magyarországi résztvevői közül az  EGroup cég a kommunikációk biztonságának kialakításában, a  Budapesti Műszaki és Gazdaságtudományi Egyetemen működő profit-orientált  Mobil Információs Központ, a  BME-MIK  pedig a nagysebességű kommunikációval kapcsolatos problémák megoldásában segítette a nemzetközi konzorciumot.

2009. július 29-én  a  MIK-ban került sor a  BOSS, Mobil Videó Megfigyelő és Utastájékoztató Rendszer  szakmai bemutatójára, melyen a kutatásban résztvevők képviselői beszámoltak a  Celtic-BOSS projekt fontosabb magyar vonatkozású eredményeiről.  A vonatkozó kutatások jelenleg az elővárosi vonatokon alkalmazható megoldásokra irányulnak.

Az uniós támogatású nemzetközi projekt elnevezése tehát Celtic-BOS, a kapcsolódó hazaié pedig Déri-BOSS. 

A Celtic típusú (EUREKA) megoldások közé tartozó BOSS project finanszírozása önerőből történik, a magyar partnerek költségeit pedig hazai pályázati pénzekből fedezték.

A bemutatón a megjelenteket a magyar konzorcium vezetője Nagy András (EGroup Services Kft.)  és dr. Imre Sándor, a BME-MIK  tudományos-kutatási igazgatója köszöntötte, majd sor került a Celtic-BOSS és a Déri-BOSS projekt bemutatására dr. Jeney Gábor,  a BME-MIK  BOSS-projekt felelőse előadásában.

A nemzetközi Celtic-BOSS projectben résztvevő cégek :

THALES, ALSTOM, SNCF, INRETS, UPMC, UCL, SILEX, TELEFONICA, ARTEIXO, INECO, BME, EGROUP.

A projekt során tehát azokat a műszaki megoldásokat keresik, amelyekkel az elővárosi vonatokon lehet növelni az utasbiztonságot.

Ilyenek lehetnek;

-videófelügyeleti rendszerek,

-hatékony videókódolási módszerek, 

-mozgás- és esemény-érzékelést támogató mesterséges intelligencia,

-olyan nagysebességű adatkommunikációs rendszer, amely a vasúti szerelvény és a földi megfigyelőállomás között teremt kapcsolatot.

További célként szerepel a megelőző karbantartási feladatok segítése, de nem cél az utasok internet-elérésének támogatása.

A Celtic-BOSS projekt eddigi menete;

A 2004-ben kezdődő előkészületi fázist követően, a konzorcium első pályázata FP6-ra vonatkozott, sikertelenül, de 2006-ban már sikerrel jártak a Celtic típusú (önfinanszírozó) projektre való pályázattal, ennek lebonyolítása 2006 októberétől 2009 júniusáig tartott, az eredmények, köztük a magyar eredmények iránt, jelentős érdeklődés mutatkozik, elsősorban nemzetközi szinten.

Az FP6  olyan, 17,5 milliárd euró összegű pénzügyi keret, melynek célja:

az európai Kutatás és Technológiai Fejlesztés (RTD) segítése, az Európai Kutatási Központok (ERA) létrehozása.

A pályázók köre:

kutatóintézeti, egyetemi kutató csoportok,  vállalatok, (előnyben a kis-és közép), ha költségvetésüknek legalább 15%-a az adott területen realizálódik,  minisztériumok,  EU-n belüli és kívüli kutatók, egyetemi hallgatók,

nemzetközi szervezetek.)

A nemzetközi Celtic-BOSS projekt eredményei:

A 4 országból, 12 partnerrel felálló nemzetközi konzorcium a projekt indításakor összegyűjtötte és elemezte a felhasználói követelményeket:

– a felvételeknek a jármű-fedélzeten való tárolása nem praktikus,  helyette más megoldásra van szükség,

– a rendszer alkalmazkodjon a speciális vasúti környezethez,

– a rendszer legyen intelligens és könnyen működtethető, erre jó a  BOSS , amelynél 

          az abnormális események  érzékelése automatikus,

          az érdekelt felek automatikus értesítést kapnak úgy a fedélzeten, mint a földi állomáson,

          azonnali távoli hozzáférés lehetséges a videokamerák képéhez és a tárolt képkockákhoz.

 -gyors reakcióidővel gyors legyen a rendelkezésre állás és magas szintű a megbízhatóság,

– egyszerű adatkezelés tegye hatékonnyá a vasúti szolgáltatót,

– az új szabályozások legyenek könnyen bevezethetők.

Mindez csökkentse a költségeket és a működtetésbe, karbantartásba való beavatkozás idejét.

A megfogalmazott igények a következő kutatási témákat indukálták:

-Hatékony vezeték nélküli kapcsolat:

       – szűkös erőforrások mellett nagyobb jelsebesség biztosítása,

       – egyszerű handover menedzsment (hálózat-váltás):  horizontális, vertikális,

       – javított QoS (Quality of Service, szolgáltatás-minőség).

– Adatfeldolgozó és esemény érzékelő megoldások fejlesztése:

       – többféle forrásból származó jelek vétele hang-, kép-, és egyéb szenzorok alkalmazásával,

       – valós idejű és kifinomult A/V megoldások.

  • – A multimédiás adatfeldolgozás- és robosztusság-javítás:

       – az átviteli csatornához való illesztés,

       – a legmodernebb kódolási algoritmusok támogatása.

Fentiekre kidolgozott kulcsmegoldások:

– hatékony vezeték nélküli kapcsolat,

– kétszintű mobil kapcsolat, UMTS(HSUPA) / WiMAX a vasúti vonal lefedésére,

– jövőbeli WiMAX-szerű MIMO megoldás kidolgozása,

– NFC (közeltéri kapcsolat) -alapú hozzáférés,

– hálózatváltások a GPS információn alapuló előrejelzés segítségével.

  • – adatfeldolgozó és esemény érzékelő megoldások fejlesztése:

            # valósidejű megoldások:  audió, videó, szenzorok,

            # jövőbeli előrehaladottabb megoldások (off-line),

  • – multimédiás adatfeldolgozás- és robosztusság-javítás:

            # valós-idejű kódolás a BARCO/THALES tömörítő kártya segítségével,

            # szoftver-alapú valósidejű videó dekódoló,

            # robosztus, bithiba- és csomaghiba-tűrő videó.

A nemzetközi Celtic-BOSS projekt néhány fontosabb megoldása:

WP2 (Workplan2,  a project 2.sz. fázisa)

– kiépült a MIMO-OFDM kétirányú RF tesztbed (WiMAX szerű),

– elkészült a WiMAX és HSUPA összehasonlító tanulmány,

– jelterjedési tanulmányok készültek a francia elővárosi vonatok fedélzetén a vezetéknélküli szenzor hálózatok   

  (WSN) és mesh hálózatok alkalmazásához (beleértve a 6LowPAN alapú IPv6 WSN integrációját a BOSS   átjáróba),

– az adatfeldolgozást a küldési és általános állapotokhoz igazították,

– tanulmányozták és használatba vették a DCCP és SCTP protokollokat,

– sikeresen osztottak el adatfolyamokat több interfészen mobil IPv6 és a handover predikciós megoldás  

  segítségével.

WP3

– megoldották az események érzékelését,

– létrejött az események menedzsmentje (feldolgozás, tárolás),

– sikerült a robosztusság javítása video jelfolyamoknál:  nőtt a hiba-ellenállóság, megoldódott az FEC

  mechanizmusok beillesztése,

– RTP/RTSP multimédia-építőelemet hoztak létre a jelfolyamokhoz,

– skálázható videó kódolókat alkalmaztak (javított AVC, "SVC"),

– optimalizált DSP könyvtár jött létre az AVC kodekhez.

WP4

– sikeresen integrálták a teljes multimédiás jelfeldolgozási láncot,

– a „végső demonstrátor"-ba  beillesztették

        # a 6LowPAN alapú IPv6 vezetéknélküli szenzor hálózatot, amely a hőmérséklet riasztások generálásáért 

           felelős,

        # a hang-események érzékelését és a hangátvitelt,

        # a képi események előállítását, a valós idejű videótömörítést,  a videóátvitelt az átviteli körülményekhez való

           azonnali adaptációval,

   Mindezt a BOSS átjárón (BOSS Gateway) keresztül, szabványos és rögzített SIP kommunikációban, megjelenítve  

   (a globális karbantartó interfészen, a PCC interfészen, specifikus audió és videó interfészeken).

Lezajlott a teljes rendszer demonstrációja menetrendi vonaton, valós körülmények között  a RENFE

(http://www.renfe.es/ , spanyol államvasutak) egy vonatán,  Madrid legnagyobb pályaudvarán, Atocha-n 2009. április 20-24. között.

A hazai BOSS projekt (Déri-BOSS)

BME – Egroup

A Celtic (EUREKA) típusú projektek jellemzői tehát:

– önfinanszírozóak, az anyagiakról minden partnernek magának kell gondoskodnia.

  • DE: minden országban célzott pályázatok állnak rendelkezésre, ahol nincs ilyen, onnan partner sem jöhet,

(pl. Cefriel, Olaszország).   Magyarországon ilyen lehetőséget jelentett az NKTH (Nemzeti Kutatási és technológiai Hivatal) Déri Miksa pályázata, ezért jött létre a magyar konzorcium az E-Group Services Kft. vezetésével, ahol a BME partnerként működik közre.  Déri Miksa pályázatuk 2005-ben sikeres volt, bár a projekt indulása körüli huzavonák és a magyar finanszírozás csúszása miatt többször módosult.  A megjelölt műszaki tartalom megfelelt a Celtic-BOSS projekt műszaki tartalmának.

A Déri-BOSS projekt szerkezete

A nemzetközi Celtic-BOSS-hoz hasonlóan, két és fél éves időtartamú volt.

A megvalósult három munkaszakasz:

2006. november 1. – 2007. május 31.

2007. június 1. – 2008. május 31.

2008. június 1. – 2009. május 31.

Az elért fontosabb eredmények:

Az E-Group-nál: 

– NFC middleware (köztesréteg) kifejlesztése,

– általános NFC alkalmazás architektúra kidolgozása,

– NFC-PKI hitelesítési modul alkalmazása IDServer-ben,

– NFC alapú azonosítás és készülék beállítás kialakítása.

A BME-n:

– SCTP és DCCP összehasonlítása és szoftver elemek kiválasztása,

– a HSUPA és a WiMAX analitikus összehasonlítása,

– a GPS alapú prediktív handover menedzsment kialakítása,

– vivőallokációs módszerek alkalmazása (WiMAX-szerű) OFDM rendszerekben,

– eredmények publikálása (könyvfejezet, folyóiratcikkek, konferenciák).

Hivatalos weboldal létrehozása, üzemeltetése (http://www.celtic-boss.org/)

A közeltéri azonosításról

Nagy András  (E-Group) előadása nyomán

A járművek fedélzetén meg kell oldani a személyzet, a telepített eszközök, ill. az utasok biztonságos kommunikációját,  a projekt fejlesztői ehhez a közeltéri kommunikációt (NFC) választották, ahol az együttműködő eszközök működése csak adott távolságon belül értelmezhető, ez jelenti a biztonsági elemet.

Az új-generációs RFID eszközök mintegy „vezeték nélküli intelligens kártyaként" működnek, az azonos fizikai réteget kezelő eszközök egyike által gerjesztett rádiófrekvenciás teret érzékeli a rendszerben hozzá közelített másik eszköz, így a hagyományosan értelmezett wireless smart card kommunikáció az NFC protokoll speciális esetének tekinthető.

Közeltéri kommunikáció létrehozható aktív-passzív és aktív-aktív (P2P, peer-to-peer) felállásban.

Az NFC-Fórum biztonsági munkacsoportjában résztvevő  E-Group a projekt során elsőként vette fejlesztési irányzatába az NFC-n alapuló biztonsági megoldásokat (SecureNFC), melyre minta-alkalmazások készültek 2006 során;

  • – biztonságos jelszó-tároló,
  • – biztonságos használati alapú szoftver-licenszek,
  • – navigáció (Nav&Go, iGo),
  • – másolás-védelem (DRM, Digital Rights Management),
  • – „Virtual Tag" alkalmazások, eTicketing (elektronikus jegykezelés) , Loyalty (kedvezmények),
  • – promóciók, hűség-programok,
  • – autentikáció.

A rádiófrekvenciás azonosítás elvén működő felügyeleti rendszereket már széles körben alkalmazzák az iparban, de speciális esetben, pl. vasúti szerelvényeknél, elosztott telepítésű működésüket, "felfűzésüket" kell biztosítani.

Erre szolgálhat a virtuális azonosító cimke, a virtual tag, amely a fizikai azonosító elemeket valamely vezeték nélküli, pl. GPS pozícionálással és térképes azonosítóval jelöli ki a rendszerben.

A rendszer működtetése során érzékeny adatok keletkeznek a riasztásokról, video és audió felvételek a fedélzetről, stb.  Ezekhez a vonat személyzetének hozzáférést kell biztosítani, szabványos, nyílt protokollokon keresztül.

A BOSS projektben előírt követelmény az erős azonosítás.

Az E-Group által kidolgozott NFC alapú megoldás saját middleware-n (köztes eszközön) és alkalmazás-architektúrán alapul, jellemzői:

– több faktorú,

– gyors és kényelmes,

– egyszerű csatolófelülettel modulként használható,

– innovatív, jövőbemutató megoldást jelent, korábban hasonló integrált eszköz nem létezett,

– biztonságos, PKI- tanúsítvány alapon működik,

– ügyfélkapu,

– autentikációs keretrendszer,

– alkalmazott autentikációs protokollok:

        # PIN – név+jelszó,

        # TAN – Transaction Authentication Number,

        #  PIN-TAN,

        #  grafikus jelszó,

        #  OTP (One-time Password) – egyszer használatos jelszó (SMS is),

        #  HOTP – HMAC alapú, egyszer használatos jelszó (mobil telefonnal is),

        #  PKI – SSL + elektronikus aláírás (wPKI – mobil SIM kártyás megoldás is),

        #  NFC/RFID passzív,

        #  PKI-NFC – a BOSS kapcsán létrejött megoldás.

Az  alkalmazott NFC middleware- és alkalmazás-architektúra felépítése, jellemzői:

  • – általános NFC alkalmazás architektúra,
  • – köztes réteg mindkét kommunikáló fél oldalán,
  • – maga a köztes réteg (middleware),
  • – magas szintű alkalmazás-interfész,
  • – egyszerű alkalmazás-fejlesztés,
  • – a szabványos NFC „kommunikációs szintű" protokoll el van rejtve az alkalmazás-réteg felől,
  • – beépített biztonsági funkciók:

           #  alkalmazás azonosítás,

           # digitális aláírás,

           # titkosítás/dekódolás,

           # biztonságos adattároló kialakítás,

           # alkalmazás elválasztás,

           # több alkalmazás egyidejű kapcsolódása.

A rendelkezésre álló, beszerezhető eszközökön az E-Group munkatársai segítségével élő bemutató zajlott a tájékoztatón: 

A bemutatóra megfogalmazott feladat:

– felhasználó hitelesítése PKI-alapú „challenge-response" protokollt használó eszközzel NFC kommunikációs csatornán keresztül,

-a videólejátszó konfigurálása NFC-s eszköz segítségével.

A felhasznált kommunikációs eszközök:

– Samsung Q1  mobil (fedélzeti) PC,   UMPC Windows XP operációs rendszerrel,

– Arygon GSM PDA AGPA 13,56 MHz,  NFC-képes PDA

– SDiD 1010,  NFC-t megvalósító SD kártya,

– Nokia N810,  Nokia maemo Linux-on futó C++ alkalmazással,

– Nokia 6131,  NFC-képes telefon, Java MIDlet futtatással, JavaCard a kriptográfiai kulcsok tárolásához,

– NFC olvasó,  Pegoda olvasó,

– fedélzeti PC,  Windows-on futó Java alkalmazással,

– hálózat vezetéknélküli kapcsolattal,

– iD Server:   E-Group authentikációs szerver, PKI challenge-response modullal.

A demo futtatott lépései voltak:

– alapállapot:   a szerverek futnak, fedélzeti PC és NFC olvasó (Pegoda) készenléti állapotban van (várakozik az NFC készülékre és a kérésekre),  a kézi készülék (Nokia N810 + Nokia 6131) alkalmazásai futnak,

– a hitelesítés indítása:  az NFC-képes kézi készülék olvasó (Pegoda) elé helyezése (max. táv 10 cm),

– kihívás kérése:  a fedélzeti PC észleli a kézi készüléket és kezdeményezi a felhasználói hitelesítést:

kér egy „challenge" (random) adatot az iD Server modultól,

–  a kihívás lenyomatolása:   az iD Server elküldi a „challenge" adatot a fedélzeti PC-nek, amelyen a futó aláíró alkalmazás elindítja az aláírási folyamatot.  A folyamat futása során az aláíró alkalmazás lenyomatot képez a „challenge" értékéről és ezt, az aláírandó adatot átadja a Nokia 6131 telefonnak.

–  a kihívás lenyomat aláírása:   a Nokia 6131 aláírja a lenyomatot (JavaCard-ban tárolt titkos kulccsal), majd visszaküldi a fedélzeti PC-nek, amely befejezi az aláírási folyamatot (letárolja a kódolt lenyomatot).

– válasz küldése:   a  hitelesség ellenőrzése céljából a fedélzeti PC elküldi a kódolt lenyomatot, mint választ („response") az iD Server modulnak,

– az ellenőrzés:   az iD Server összeveti a válaszként visszakapott kódolt lenyomatban levő lenyomat értékét az általa (ugyanazon „challenge" értéken) kiszámolt lenyomattal,

–  engedélyezés/elutasítás:    az iD Server modul kiértékeli az aláírást az összevetés alapján (egyezik vagy sem).

Ha nem egyezik, akkor hibaüzenettel leáll, és kezdeti állapotba kerül. Ha jó, akkor lekéri a konfigurációs adatbázisból az adott felhasználóhoz tartozó profilt (key.txt) és elküldi a fedélzeti PC-nek.

–  konfiguráció letöltése:   a fedélzeti PC továbbküldi a konfigurációs állományt (key.txt) a kézi készülékre

(Nokia N810 + Nokia 6131), amely tárolásra kerül. Hiba esetén nem fér hozzá a konfigurációs állományhoz, a Nokia N810 felé csak hibaüzenet kerül elküldésre.

–  videó dekódolása:   a key.txt állományból kiolvasott kulccsal dekódolódik a kódolt adatfolyam és láthatóvá válik a kamera képe.

A demonstráció tanulságai:

-a megvalósított implementáció rendelkezésre áll, akár egy új projektre is lehetőséget ad,

– a  mobil szolgáltatótól natív IPv6-os lefedettségre van szükség,

– a  WLAN hálózatokban is natív IPv6-os lefedettség szükséges,

– az utasoknak akár internet hozzáférés is biztosítható,  utastájékoztatás lehetséges,

– kommunikációs platform biztosítható bármilyen szolgáltatáshoz,

– a továbbiakban mindez tesztelhető nagyobb területen (teljes vonalhálózaton).

A GPS-alapú mobilitáskezelő rendszer elméleti összefoglalója

Bokor László,  BME-MIK előadásában

A  BOSS (On Board Wireless Secured Video Surveillance)  projekt célja olyan innovatív kommunikációs rendszer kifejlesztése volt,

ami a tömegközlekedési járművek és diszpécserközpontok közti hatékony információátvitellel megfelelő hálózati platformot nyújt a

karbantartások, fedélzeti biztonsági műveletek, információs szolgáltatások, és diagnosztikai eljárások távoli vezérléséhez, valamint

az internet hozzáférés biztosításához.

Az internet-hozzáférés biztosítása gondot jelent mozgó járművön, mivel az internetet fix (rögzített csatlakozási pontú) csomópontok

használatára tervezték.  Az internet protokollnál (IP)  jelenleg a 4-es változat (IPv4) van általános használatban,  az IPv6 még nem

terjedt el eléggé.

Tervezési problémát jelent, hogy az  IP cím szemantikailag túlterhelt (korábban nem gondoltak a mobilitásra), további gond az

interfész azonosító szerep (identifier)  és a topológiai helymeghatározó szerep (locator).  

Mozgó járművökön időben változhat a használt csatlakozási pont (pl.: a vonat nagy távolságokat szel át),  ez sokszor a használt IP cím

változásához (alhálózat váltáshoz) vezet.

Az IP cím kommunikáció közbeni („on-the-fly") módosítása megszakítja a futó kapcsolatokat.

Az IP cím változatlanul hagyása alhálózat-váltásnál a csomagok útvonalirányítási mechanizmusaiban hibákat okoz.

Mindezek miatt speciális, mobilitást támogató kiegészítésekre van szükség,  melyet az új IP verzió (IPv6) sok beépített funkcióval

támogat is.

Az IP szintű mobilitás fogalmai

A hoszt mobilitásnál:

– egyetlen mobil terminál van,

– alhálózat váltása esetén új, topológiailag helyes cím szerzése történik.

Hálózat mobilitásnál  (NEMO, NEtwork MObility):

– egész hálózat mozog, egyetlen egységet alkotva,

– mobil útválasztó (Mobile Router) rejti el a hálózat belső jellemzőit a külvilág elől,

– a hálózat mozgásakor:

            # az MR változtat IP címet,

            # a mozgó hálózat belsejében lévő csomópontok nem érzékelik a változást, nincs feladatuk ezzel kapcsolatban.

A  MCoA (Multiple Care-of Addresses Registration) :

– Az MCoA a NEMO BS protokoll kiterjesztése, mellyel megvalósítható, hogy a MR egyszerre több ponton is kapcsolódjon az Internethez, akár több fizikai interfésszel.

– A MR továbbra is egy otthoni címmel rendelkezik de a kötés kiegészül egy BID (Binding Unique Identifier) azonosítóval, amivel a kimenő interfész és ezáltal a kétirányú NEMO alagutak (az MN kötései) beazonosíthatók.

– Sem a szabvány, sem az implementáció nem határozza meg, hogy mikor melyik interfészt kell használni a csomagtovábbításhoz!

A  Flow Binding:

– a Flow Binding mechanizmusai lehetővé teszik, hogy egy vagy több adatfolyamot kössünk a mobil adott ideiglenes címéhez és felkészítsük az otthoni ügynököt is a mobil felé irányuló csomagok adott címre történő irányítására.

– Linux rendszeren ez a policy alapú útvonalválasztás a netfilter keretrendszer csomagjelölő (MARK) képességinek segítségével valósítható meg.

– A csomagok adott útvonalon való küldése érdekében a csomagokat az adott útvonalhoz tartozó interfész BID-jével jelöljük meg az útvonalirányítás előtt.

– Az MCoA implementáció ezután már elvégzi a többit: az adott BID-del jelölt csomagokat az adott BID-hez tartozó útvonalirányítási szabályoknak megfelelően továbbítja.

A prediktív hálózatváltás –  a probléma

  • – A hálózatváltások során elvégzendő feladatok:

           #  új hozzáférési hálózatok keresése (scanning),

           #  hitelesítés, hozzáférés-menedzsment (authentication, authorizaton),

           #  csatlakozás (association),

           #  IP címmel kapcsolatos műveletek:

új cím szerzése (acquiring Care-of Address),

új cím ellenőrzése (Duplicate Address Detection),

a régi cím (és a hozzá tartozó routing bejegyzések) törlése (deletion of previous entries),

               #  IP szintű mobilitáskezelés:

regisztráció az otthoni ügynöknél (registration to HA),

regisztráció a kommunikációs partnereknél (registration to CNs).

– A mobilitás kezelése időigényes, ami a valós idejű (real-time) kommunikációt az okozott csomagvesztés, késleltetés miatt könnyen ellehetetlenítheti!

– Kötött pályán vagy rögzített útvonalon mozgó járművek esetén nagy előny, hogy feltérképezhetjük az út során elérhető hálózatokat, így felkészülhetünk a hálózatváltás folyamataira, amivel jócskán csökkenthetjük a hálózatváltás okozta extra késleltetés mértékét!

Megoldási alap-ötlet:

– Multihomed MR esetén a NEMO hálózatváltást gyorsíthatjuk, ha előbb egy nem használt interfésszel felcsatlakozunk az új hozzáférési hálózatoz, s elvégezzük az összes járulékos feladatot,

– ha készen vagyunk, áttereljük az összes forgalmat a régi alagútról az újra, ezáltal akár csomagvesztés nélkül végrehajthatjuk   

  az átváltást,

– ilyen esetben egyszerre mindig csak egy interfész lesz aktív, de a hálózatváltás előtt egy nem használt interfésszel felcsatlakozhatunk az új hálózatra és a policy szabályok módosításával végrehajthatjuk az átállást, minimálisra csökkentve a hálózatváltáshoz szükséges időigényt és forgalomkiesést.

Az így megfogalmazott rendszer felépítése:

A HM feladata lesz, hogy aktív és passzív mérésekkel információt nyerjen az elérhető hálózatok fizikai, adatkapcsolati és hálózati rétegeiből.

A HM a mérésekhez időbélyegeket rendel, majd periodikusan elküldi az ANP modul számára.

Az ANP modul a kapott információkat GPS koordinátákhoz rendeli és saját adatbázisában elmenti. Amennyiben olyan földrajzi helyen járunk, ahol már korábban tartózkodtunk, és a HM modul már feltérképezte az elérhető hálózatokat, akkor az ANP modul a közeljövőben elérhetővé váló hálózatokról időbeli előrejelzést szolgáltat a HM modulnak.

Az előrejelzések alapján a HM kiválasztja és inicializálja a használandó új interfészt és ennek megfelelően időzíti az alagutak átállítását az MR és a HA komponensekben.

Ehhez a kijelölt feladatok:

– pozíció+mért adat vétele,

–  adatbázis karbantartás,

– pozíció előrejelzése,

– access network előrejelzés.

Az eszközök:

  • – GPSD (GPS előfeldolgozás),
  • – PERL+CPAN (a használt programnyelv),

– MySQL (adatbázis szerver).

Az elérési hálózat megvalósítása során sikerült :

  • – testbed-et kialakítani, (valós idő – mobil környezet),
  • – eligazodni az adattengerben (vizualizálás) ,
  • – a valós idejű adatfeldolgozás (rövid feldolgozási idővel),
  • – párhuzamos eljárások (processzek) kialakítása:

               # GPS pozíció vétel,

               # HM modultól valóvétel,

               # adatbázis karbantartás,

               # access network elérhetőség valószínűségének biztosítása,

–  a kommunikáció a párhuzamos processzek között.

Handover Management – hálózati mérések :

802.11x :

– egy WiFi interfész monitor módban:   ezen az interfészen látható lesz minden 802.11 eszköz forgalma (a teljes 802.11 réteggel és egy driver-specifikus monitoring fejléccel)

– a kinyert információk:

            #  BSSID:  48 bites hálózat azonosító,

            #  SNR:   a monitoring fejléc miatt minden csomagban szerepel,

            #  hálózati prefix:   IPv6 és ICMPv6 protokollanalízist végezve RA üzenetekből nyerhető ki,

3G UMTS :

  • – függetlenül attól, hogy kapcsolódva vagyunk vagy sem, lehetőségünk van egy menedzsment portra csatlakozni, amin keresztül információt kaphatunk a jelerősség aktuális értékéről, a modem által mért RSSI (Received Signal Strength Indication) értékek alapján,
  • – a kinyert információ: RSSI – viszonyszám a vételi körülményekről,

               

Handover Management – a döntési algoritmus :

– Az ANP-től periodikusan (másodpercenként) kapott előrejelzések alapján a HM folyamatosan figyeli a hálózatokat és dönt az esetlegesen szükséges hálózatváltásokról.

– Minden predikció tartalmazza azt az időpontot amitől kezdve a predikció érvényes (starttime) és azt az időintervallumot ami alatt az adatok valódiak (range). Ezen értékek alapján meghatározható, hogy szükség van-e hálózatváltásra.

– Ha hálózatváltás szükséges, akkor a következő lépés a célhálózat kiválasztása a legfrissebb előrejelzésből. Az algoritmusban jelenleg statikusan meghatározott, hogy egy predikált WiFi hálózat mindig prioritást élvez az alapértelmezett 3G-vel szemben, így nincs más dolgunk mint médium, azon belül pedig SNR érték szerint sorbarendezni a hálózatok listáját és a legelső WiFi elemmel inicializálni a hálózatváltást.

– Látható, hogy a prototípus egyszerű döntési algoritmust használ, mely azonban tetszőlegesen kiterjeszthető (pl. aktív /IP szintű/ mérésekből származó adatok feldolgozására).

Handover Management – hálózatváltás

– Két komponens található:   MR és HA (köztük a kommunikácó XML alapokon zajlik).

– Az ANP-től érkező előrejelzések alapján döntünk a használandó interfészről (BID).

– Mielőtt a HA felé bármit is jeleznénk, elő kell készítenünk az új hálózatot.

          #  WiFi kapcsolatok kezeléséhez két db eszközre van szükség (WiFi-WiFi váltás!), de ezekből mindig csak az egyik aktív, így a másik -nem használt- interfész használható az új hálózatra való kapcsolódás előkészítésére.

          #  ha a jelenlegi hálózat 3G, akkor az új hálózat csak WiFi lehet, de mivel azok közül egyik sem használt, tetszőlegesen kiválasztunk egy interfészt és a predikcióban megkapott AP MAC címre felcsatlakozunk.

          #  ha jelenleg az egyik WiFi eszköz használatban van, és a következő hálózat szintén WiFi, akkor a nem használt interfésszel kell kapcsolódnunk.

         #  amennyiben a kapcsolódás sikeres, várunk amíg az előrejelzés alapján még várhatunk (időt hagyunk a NEMO alagutak kiépülésének).

         #  az előkészületek után már elküldhetjük a HA-nak a Prediktív Policy Exchange üzenetet.

– A HA részére elküldendő Prediktív Policy Exchange üzenetben adjuk meg, hogy melyik BID azonosítóval rendelkező alagútra melyik időpillanatban kell majd váltanunk (azaz melyik interfészt /hálózatot/ kell használnunk).

– Az elküldött Prediktív Policy Exchange üzenetre érkező pozitív nyugta esetén a döntés során meghatározott késleltetés után módosításra kerülnek a policy szabályok mind a MR, mind a HA oldalán.

–  Ha a két oldalon egyszerre történik a szabályok módosítása, akkor egyszerre fog a forgalom átterelődni a másik

(új interfészhez tartozó) alagútra.

Konklúziók:

A GPS alapú prediktív handover menedzsment rendszerrel

–  gyorsabb a hálózatváltás,

  • – megbízhatóbb a kommunikációs csatorna,

– a megvalósított implementáció rendelkezésre áll, akár egy új projektre is lehetőséget ad,

– az utasoknak internet hozzáférést és tájékoztatást biztosítanak,

– kommunikációs platform áll rendelkezésre,  bármilyen szolgáltatáshoz,

– további, nagyobb vonalkiterjedésen lehet tesztelni.

http://www.celtic-boss.org/ 

http://celtic-boss.org/ 

http://www.spec.hu/palyazatcikk.htm

http://icfamon.dl.ac.uk/DataTAG-WP2/ 

http://en.wikipedia.org/wiki/Atocha_railway_station

http://www.nkth.gov.hu/ 

http://www.egroup.hu/

http://drm.info/

http://eprints.soton.ac.uk/53332/ 

Harmat Lajos

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük