A Bluetooth L2CAP protokolljának elemzése és formális leírása

Dulai Tibor Veszprémi Egyetem, Információs Rendszerek Tanszék

dtibor@vekoll.saturnus.vein.hu

Harmatné Medve Anna Veszprémi Egyetem Információs Rendszerek Tanszék

medve@almos.vein.hu

Dr Tarnay Katalin Veszprémi Egyetem, Információs Rendszerek Tanszék

katalin.tarnay@irt.vein.hu

Az információs forradalom korszakában a kapcsolattatás elengedhetetlen fogalma az egymással kommunikáló eszközök által kialakított hálózat. Számos esetben - ez a mobil készülékek esetén fokozottan érvényes - a kábelekkel történõ összeköttetés többnyire lehetetlen, vagy nagyon költséges beruházást igényel.

A kábeles csatlakozás kiküszöbölésére több technológia fejlõdött ki, a rádiós átvitel azonban számos tényezõben elõnyösebbnek bizonyult a többivel szemben, nem követeli meg a kommunikáló felek egymásra való rálátását, robosztus, viszonylag gyors átvitelt valósít meg olcsón. Ilyen rádiós kapcsolatra épül a Bluetooth technológia, mely a 2.4 GHz-es ISM sávban FSSH-t alkalmazva legfeljebb 10 m-re történõ, maximálisan 1 Mbps sebességû átvitelt valósít meg.

Elõadásomban a rövidtávú vezetéknélküli hálózatok bemutatása után a Bluetooth adatkapcsolati rétegét írom le formális nyelvek segítségével, melyekkel könnyen ábrázolhatók olyan dinamikus, valós idejû, interaktív elosztott rendszerek, mint a protokollok.

Kulcsszavak: protokoll technológia, vezetéknélküli hálózatok, formális nyelvek, SDL, Bluetooth

The Design of the Data Link Layer Protocol of Bluetooth using the Formal Method Technique

Network created by the devices communicating to each other is an essential concept of the connection at the age of the informational revolution. In several cases - especially between mobile devices - the connection via wire is not possible or very expensive.

Many wireless technologies have been developed. The radiowave connection has more advantages than the others because the communicating devices do not need to be visible to each other, the technology is robust and offers quick and cheap transmission. Such radio connection is the basis of Bluetooth technology. It communicates in the ISM band at 2.4 GHz applying FSSH and offers transmission in 10 meters distance at the speed of 1 Mbps.

After presenting the short range wireless networks I will describe the data link layer of Bluetooth making use of formal method techniques. These techniques are suitable for present dinamic, realtime, interactive distributed systems like protocols.

Keywords: protocol engineering, wireless networks, formal method techniques, SDL, Bluetooth

A Bluetooth L2CAP protokolljának elemzése és sokoldalúan hasznosítható formális leírása

Készítette: Dulai Tibor

Veszprémi Egyetem, Mûszaki Informatikai és Villamosmérnöki Önálló Intézet,

Információs Rendszerek Tanszék

Bevezetés

A digitális információcsere az élet egyre több színhelyén hódít teret, köszönhetõen a mind nagyobb számban piacra kerülõ eszközöknek (mobiltelefon, PDA, digitális fényképezõgép, digitális mérõmûszerek, stb.), melyek számítógépeinkkel (gyakran alkalmi) hálózatot alkotva jelentenek megoldást az információ nyeréséhez, átviteléhez, megjelenítéséhez. Ezeket alkalmazva az intelligens otthonokban, irodákban az átvitel jellege rövidtávú.

A helyváltoztatás, a könnyû elérhetõség követelményeként megjelent és mára robbanásszerûen elterjedt mobil eszközök, valamint számos késõbb említésre kerülõ indok sok esetben nem teszi lehetõvé a kábelek segítségével történõ kapcsolódást, így más átviteli technológiák terjedtek el ezeken a területeken.

E technológiák közül az egyik legígéretesebb a SIG csoport által 1999-ben kifejlesztett Bluetooth rendszer, mely rövid hatótávolságú, viszonylag gyors rádiós adatátvitelt valósít meg. Mint az a telekommunikációval foglalkozó irodalomra jellemzõ, a hazai irodalomban újdonságokkal legfeljebb megemlítés szintjén találkozhatunk, a külföldi irodalomban könyvek szintjén többnyire csak a szakma alapjait megfogalmazó kérdésekrõl olvashatunk színvolalas mûveket (pl. Tanenbaum mûvei). A fejlõdési irányvonalakról konferenciákon, konferenciakiadványokból értesülünk. A pontos fejlesztõi specifikáció azonban csak súlyos pénzösszegekért elérhetõ, egyébként nem, így az oktatási intézményeknek nem adatik meg a lehetõség ennek megszerzésére, ezáltal a fejlesztésbe történõ bekapcsolódásba. A szabványügyi szervezetektõl csupán a rendszer felhasználói dokumentációja érhetõ el szabadon, ugyanakkor kereskedelmi célzattal a rendszer formális leírásával (SDL, MSC) rendelkeznek. Hasonlóan a fejlesztésben részt vevõ nagyvállalatok (Ericsson, Nokia, IBM, Intel, Toshiba) is belsõ információként kezelik a részleteket, a Telelogic is kifejlesztette a teszteseteket a Bluetooth vonatkozásában, melyeket a fejlesztõk nem csekély összegért megvásárolhatnak, valamint számos kereskedelmi cég rendelkezik a rendszer alapjainak implementációjával [1], melyet alkalmazásspecifikus továbbfejlesztésre árusít Bluetooth alapú végberendezések gyártóinak. Oktatási környezetben egyetlen megoldás a szabadon rendelkezésre álló információk alapján rekonstruálni a rendszert és megvalósítani.

A megvalósításban nagy segítséget nyújtanak a formális nyelvek alkalmazását lehetõvé tevõ fejlesztõi környezetek, ezáltal alkalmazásspecifikusan, esetünkben a protokoll dinamizmusát figyelembe véve teljes mélységében ábrázolni tudjuk a rendszert, mely a CASE eszköznek köszönhetõen könnyen validálható, tesztelhetõ, majd más programozási nyelvre átültethetõ.

Célom a fenti körülményeket figyelembe véve és az ingyenes szabványt alkalmazva a Bluetooth rendszer L2CAP adatkapcsolati protokolljának elemzése, megtervezése és leírása SDL nyelven.

Bluetooth <-> IrDA [2] [3]

A Bluetooth és az IrDA tûnik eluralkodni a kis hatótávolságú, kábel nélküli kommunikáció piacán.

	Bluetooth	IrDA
átviteli közeg	2400-2485 MHz-es rádióhullám	Infravörös fény
látószög	360°	30°
hatótávolság	max. 10 m (erõsítéssel 100 m)	max. 1 m
átviteli sebesség	max. 1 Mbps	max. 16 Mbps

1. táblázat

Az IrDA (Infrared Data Association) [4] - mint a neve is mutatja - infravörös fényt alkalmaz az átvitelre, ebbõl származik az egyik lényeges tulajdonsága: a kommunikáló eszközök közötti rálátás szükséges a zavartalan adatcseréhez, a jelet 30°-os szögben sugározza az eszköz. Ez lehet elõny illetve hátrány is, mely teljes mértékben az alkalmazás elvárásaitól függ. Elõny abban a szituációban, ha pl. két személy elektronikus bankkártyával történõ kommunikációt kezdeményez egymással egy teremben, ahol többen hasonló mobil eszközzel rendelkeznek. Ekkor a kis látószög és a rövid (1 m-es) hatótávolság már a fizikai szinten hozzájárul az adatátvitel biztonságához.

A Bluetooth [5], mivel 2.4 GHz-es rádióhullámokkal kommunikál, tehát iránytól független, szilárd (nem fém) anyagokon is áthatoló közeggel, a fenti körülményekre nehezebben implementálható, mint az IrDA. Ugyanakkor a rádióhullámok irányfüggetlensége lehetõvé teszi azt, hogy mikor a két eszköz egymás közelébe ér, köztük a kommunikáció már akkor elkezdõdjön, így azok szinkronizációja végbemegy anélkül, hogy tulajdonosaik kivették volna mobil készüléküket a zsebükbõl. Ez a tulajdonság, kiegészítve azzal, hogy az adatcserét végzõ eszközöknek nem kell fixen egy pozícióban állniuk a szinkronizációhoz, mint az IrDA esetén, hanem a felhasználó szabadon mozoghat, a mobilitás hatalmas elõnyét nyújtja a Bluetooth-eszköz tulajdonosainak.

Átviteli távolság szempontjából a Bluetooth 10 m-es hatótávolsággal bír (ez erõsítõve 100 méter is lehet), az IrDA esetén 1 m-es távolságról beszélhetünk, ugyanakkor adatátviteli sebességben a Bluetooth marad alul (maximálisan 1 Mbps), szemben az IrDA jelenlegi 4 Mbps-t megvalósító átvitelével, ahol már a 16 Mbps-al kommunikáló rendszer is fejlesztés alatt áll.

Mint a két technológia tulajdonságaiból is látszik, nem mondható el egyikrõl sem, hogy összességében jobb a másiknál, mindkét rendszernek vannak erõsségei illetve gyenge pontjai. Az, hogy melyiket használjuk, teljesen alkalmazásspecifikus. A két rendszer jelenlegi állapotában kiegészíti egymást: ahol az egyik gyengébb, ott erõsebb a másik, és fordítva. Az IrDA fejlesztõcsoportja kidolgozott egy felsõbb rétegbeli protokolt (OBEX, Object Exchange [6]) a viszonyrétegben, mely az adatok (objektumok) cseréjérõl gondoskodik függetlenül attól, hogy Bluetooth vagy IrDA van alatta, így az alkalmazások hordozhatóvá váltak a két rendszer között.

Ugyanakkor egy rendszernek, mellyel szélesebb körû kommunikáció valósítható meg, megvan az az elõnye, hogy megfelelõ korlátozások beiktatásával átveheti a másik, korlátozottabb technológia szerepét, ezért választottam a Bluetooth-t.

A Bluetooth

Általános jellemzõk

A technológia szabványosításáért, fejlesztéséért felelõs csoportot - mely a SIG (Bluetooth Special Interest Group) [5] nevet viseli - 1999 végén alapították 5 IT cég (Ericsson, Nokia, IBM, Intel, Toshiba) részvételével, jelenleg kb. kétezer vállalkozás a tagja. A szabvány jogdíj nélkül szabadon hozzáférhetõ.

A X. században élt és a viking birodalom felvirágoztatásáért felelõs király nevét viselõ technológia a 2400-2483.5 MHz-es (ISM) frekvenciasávot használja - mely szinte világszerte szabadon használható. Az interferencia csökkentésére FHSS-t (Frequency Hop Spread Spectrum) alkalmaz, így a sávot csatornákra osztva a kommunikáció során pszeudo-random módon a csatornák közt ugrál. Lelke egy miniatûr rádió alacsony áramfogyasztással, melynek ára tömeggyártás esetén nem lesz több egy kábelénél, így ebbõl a szempontból is alkalmas a kábelek helyettesítésére. Az elsõ generációs eszközök ára 20$ U.S., de ez a jövõben 5$ U.S. körül fog mozogni.

A Bluetooth protokoll a vonalkapcsolás (SCO - Synchronous Connection-Oriented) és a csomagkapcsolás (ACL - Asynchronous Connection-Less) kombinációját használja. Támogatja az aszinkron adatcsatornát, képes három szimultán szinkron hangcsatorna átvitelére, vagy egy csatornán akár szinkron hang- és aszinkron adatátvitelt is megvalósíthatunk vele. Minden egyes hangcsatorna egy 64 kb/s átvitelû csatornát jelent mindkét irányban, az aszinkron csatorna pedig maximálisan 723.2 kb/s sebességet biztosít aszimmetrikus esetben (visszirányban maximum 57.6 kb/s járul még ehhez), szimmetrikus esetben ez 433.9 kb/s-t jelent.

A rendszer mind a pont-pont, mind a pont-többpont kapcsolatot támogatja. Az azonos csatornán osztozó készülékek pikohálózatot alkotnak. Egy pikohálózatban egy készülék birtokolja a master szerepét - õ szabja meg a csatornahozzáférést - a többi eszköz slave. Pikohálózatonként a slave eszközök maximális száma hét. Egy csatorna frekvenciájára az FHSS alkalmazása miatt egy pszeudo-random ugrássororozat jellemzõ, melyet a master határoz meg. A névleges ugrássebesség: 1600 ugrás/s. Egy készülék több pikohálózatban is részt vehet idõmultiplexeléssel, így egy pikohálózat mastere egy másik pikohálózatban slave szerepet is betölthet.

A rendszert tulajdonsága miatt használhatjuk asztali illetve hordozható számítógépek, digitális kamera, fényképezõgép, billentyûzet, nyomtató, egyéb I/O eszközök összekapcsolására, például mérõberendezésektõl adatokat gyûjthetünk be mobiltelefonunkra, de alkalmazható az automatizált gyártórendszerek esetén is, hogy csak néhányat említsünk a lehetõségek széles tárházából. Már számos vállalat foglalkozik Bluetooth kártyák gyártásával, forgalmazásával. [7] [8] Jelenlegi talán legelterjedtebb alkalmazása a mobiltelefon és kiegészítõi (pl. headset) közti adatátvitel megvalósítása.[9]

A saját Bluetooth eszköz minden felhasználónak egy egyéni, számára kialakított interfészt biztosíthat. Ennek következtében a fogyatékosok is tudják használni az egyébként nekik nem megfelelõ perifériákat, Bluetooth-eszközükel vezérelhetik a hardvert, amin dolgozniuk kell. [10]

A Bluetooth tulajdonságai nem csak a hagyományos kommunikációs megoldások helyettesítére, hanem új távlatok megnyitására is lehetõséget ad. A rövidtávú átvitelt kihasználva lehetõvé válik a repülõgépeken mobiltelefonok, laptopok és egyéb mobil kommunikációs eszközök használata, melyek eddig tiltva voltak az okozott interferencia miatt. [11]

A Bluetooth rétegei [6] [12]

1. ábra

A legalsó réteg, a Bluetooth Radio a 2,4 GHz-es frekvenciasávban mûködõ rádió adó-vevõvel szemben támasztott követelményeket (pl. teljesítmény, moduláció, érzékenység) definiálja.

A következõ szinten található a Baseband/Link Controller réteg, mely a rendszer tulajdonképpeni fizikai rétegét jelenti. Feladata a fizikai csatorna menedzselése, a felette levõ rétegnek olyan szolgáltatásokat nyújt, mint más Bluetooth készülékek keresése, hibajavítás, torlódásvédelem, szinkronizáció, alapvetõ biztonság. [13]

Az LMP (Link Manager Protocol) által küldött PDU-k a kapcsolat felépítését, authentikációt, konfigurációt tesznek lehetõvé. A kommunikáló felek ezen protokoll keretein belül veszik fel a kapcsolatot, azonosítják egymást, egyezkednek az egymás közötti kódolásról, jelzik a másik fél felé a kapcsolattípus, -minõség megváltoztatásának szándékát.

A HCI (Host Controller Interface) egységes parancs-felületet biztosít a Link Manager, a Baseband funkciók elérésére, lehetõvé teszi a hardverállapothoz, illetve a vezérlõregiszterekhez való hozzáférést. Valójában három részbõl áll, ez a három a Host, a Transport Layer és a Host Controller. Ez utóbbi a Bluetooth hardvert, a Host a szofvert jelenti, és a HCI specifikus parancsokat a Transport Layeren keresztül továbbítja a Host a Host Controller felé, valamint ezen a rétegen keresztül tájékozódik a hardver állapotáról.

Az L2CAP (Logical Link Control and Adaptation Protocol) az adatkapcsolati rétegben helyezkedik el. AZ L2CAP implementációjának képesnek kell lennie protokoll multiplexelésre, csomagtördelésre és összeállításra, a kapcsolat minõségi paramétereinek kontrollására és címzési csoportok kezelésére. A fentebb említett ACO és SCL kapcsolatok közül az L2CAP csak az ACL kapcsolatokat támogatja, így az audiocsatornák a Baseband SCO kapcsolatain futnak. A protokoll által nyújtott szolgáltatások a csatorna, az azon lezajló kommunikáció fogalma köré épülnek: megkülönböztet jelzésekre használt csatornát, kapcsolatorientált adatcsatornákat és csoportok esetén használt kapcsolatmentes csatornákat.

Az SDP (Service Discovery Protocol) feladata az elérhetõ szolgáltatások felfedezése és ezek jellemzõinek megállapítása. A Bluetoothban alkalmazott SDP a rendszer dinamikusan változó környezetére lett kihegyezve. A protokoll alapja a szerver-kliens felépítésen alapuló kérés-válasz modell. Lehetõség van a környezetben fellelhetõ szolgáltatások felfedezése mellett konkrét szolgáltatás keresésére is. A szolgáltatás lehet információszolgáltató entitás, valamilyen akció végrehajtása, vagy más entitás viselkedését befolyásoló paraméterek kezelése. Az SDP-nek nagy szerepe van a hálózatok erõforrásmegosztásának támogatásában is.

Az RFCOMM protokoll az L2CAP felett soros port(ok) emulációját nyújtja, a Bluetooth szállítási rétegének protokollja. A protokoll az ETSI TS 07.10. szabványa alapján készült [14], maximálisan 60 szimultán kapcsolatot képes biztosítani két Bluetooth eszköz között, a tényleges szám implementációfüggõ. Az RFCOMM az RS-232 interfész 9 áramkörét emulálja, kezeli a többszörös emulált RS-232 kapcsolatokat, valamint kiegészítõ jellegû torlódásvédelmet is végez. Erre a szállítási rétegére épülve számos protokollt alkalmazó készülék használhatja a Bluetooth technológiát: alkalmazható IrDA-val ellátott eszközök (OBEX protokoll), mobil (WAP), illetve vezetékes internetet nyújtó készülékek (IP protokoll) alatt, kiszélesítve a Bluetooth lehetõségeit.

Logical Link Control and Adaptation Protocol (L2CAP)

Az L2CAP protokoll felsõbb rétegeknek nyújtott szolgáltatásai a kapcsolatorientált, illetve kapcsolatmentes adattovábbítás, a protokoll multiplexelés, csomagok széttördelése és összeállítása, a kapcsolat minõségének kontrollálása, csoportok képzése és kezelése, 64 kbyte méretig lehetõséget nyújt L2CAP csomagok adására és vételére. A protokoll ACL kapcsolatokra lett definiálva, a fizikai réteg adatintegritás ellenõrzésére hagyatkozik.

Protokollmultiplexelésre azért van szükség, mert a fizikai (esetünkben Baseband) réteg nem támogatja a különbözõ felsõbb rétegbeli protokollok PDU-ba ágyazott típusmezõben történõ megkülönböztetését, ezért ezek közt (SDP, RFCOMM, TCS - Telephony Control) az L2CAP-nak kell tudni különbséget tenni.

A Baseband réteg által használt csomagok méretei korlátozva vannak, az engedélyezetten maximális méretû csomagok (MTU - Maximal Transmission Unit) határozzák meg a hatékony sávszélesség használatot, ugyanakkor a felsõbb rétegek nagyobb csomagméretekkel dolgoznak. Így elengedhetetlen a felsõbb réteg csomagjainak feldarabolása Baseband MTU-kra, míg a vett Baseband-csomagok egyesítése a felsõbb rétegekben elfogadott méretekre a hatékony munkához (SAR - Segmentation and Reassembly).

Az L2CAP lehetõséget ad a Baseband által kialakított pikohálózaton belül csoportok kialakítására, ennek segítségével ezeken a csoportokon belüli eszközök egyszerre címezhetõk.

A protokoll csatornákon keresztül küldi a társentitásnak az adatokat, valamint a vezérlõ jeleket. A jelzési csatorna forgalmát képezõ jeleket szintén a SIG specifikációja definiálja:

Érvénytelen/hibás csomag elutasítása: Command Reject
Kapcsolatfelépítésre vonatkozó parancsok: Connection Request, Connection Response
Kapcsolatállapot kontrollálásával összefüggõ parancsok: Configure Request, Configure Response, Echo Request, Echo Response, Information Request, Information Response
Kapcsolatlebontás esetén használt parancsok: Disconnection Request, Disconnection Response

A Configure Request parancshoz kapcsolódó opciók alapján a kapcsolat különbözõ paraméterei állíthatók be. A kommunikáló felek megegyezhetnek az MTU méretében külön-külön mindkét irányban, az idõzítési paraméterekben, valamint a szolgáltatás minõségében. A szolgáltatás alapvetõen a legjobbra való törekvés jegyét viseli magán (Best Effort), de kérhetõ garantált szolgáltatás is (sávszélesség, késleltetés tekintetében).

A formális nyelvek szerepe a protokollok leírásában [15]

A kommunikációs protokollok jellemzõen valós idejû, interaktív elosztott rendszerek a maguk dinamikájával. A hagyományos szoftverfejlesztés problémái a nem elég mély ábrázolási mód, illetve a rendszer dinamikus viselkedését nem tükrözõ megoldások alkalmazása. Az elõbbi miatt a rendszer mûködése teljes részletességgel csak a megvalósítási fázisban készült el, így erõsen implementációfüggõ lett, más programozási környezetre történõ átültetése komoly feladatot jelentett. A rendszer dinamizmusának elhanyagolása a helyes mûködést vizsgáló tesztek során a statikus részekre jól tervezett, alapos, minden eshetõségre figyelõ munkát kíván, így ez a fázis a szoftverfejlesztés során jelentõs költségeket és idõt emészt fel.

A technológiák fejlõdésével, a CASE eszközök, a mesterséges intelligencia megjelenésével, matematikai módszerekkel, mély elméleti háttérrel a fenti problémákat kiküszöbölõ leírási módok születhettek meg. Szimbólumok segítségével a rendszer teljes mértékben leírható, az egyes elemek közötti kapcsolatrendszer a maga dinamikájával hûen ábrázolható. A szimbolikus leírás segítségével a validálási folyamat leegyszerûsödik, a tesztelés automatizálható, és a validált, tesztelt specifikációból a futtatható kódot a CASE eszköz akár több programozási nyelvre is elõállítja.

Ilyen formális nyelvek az SDL (Specification and Description Language) specifikáló és leíró nyelv, az MSC (Message Sequence Chart), mely a rendszer elemei közti kommunikációt írja le idõsordiagrammok segítségével, a TTCN (Tree and Tabular Combined Notation), mely a teszteléshez szükséges tesztkészleteket hivatott definiálni, illetve az elõbbiekre egységesen használható ASN.1 (Abstract Syntax Notation One) adatdefiníciós nyelv.

Az SDL matematikai alapja a kiterjesztett véges automata modell: EFSM = (S, I, O, A, V, P, s₀, f_{s, I, p}). [16] A jelölések: S az állapotok véges halmaza, I a bemenetek véges halmaza, O a kimenetek véges halmaza, A az akciók véges halmaza, V a változók véges halmaza, P a predikátumok véges halmaza, s₀a kezdõállapot, míg f_{s, I, p} az állapotátmenet-függvény. A bemenet és a kimenet az automata és környezete közti kommunikációs események, az akciók a változókon hajtódnak végre a bemenetek hatására, a változók pedig a predikátumok alapján hatnak a kimenetre és az állapotátmenetre. Az állapotátmenet-függvény azt definiálja, hogy az automata i bemenet hatására s_k állapotból p feltétel mellett milyen a akciót hajt végre, mi lesz az o kimenet és mi lesz a következõ s_k+1 állapot.

Továbbiakban konkrétan az SDL nyelv segítségével ismerjük meg jobban a Bluetooth L2CAP protokollját. A rendszer SDL leírásához a Telelogic Tau 4.1 fejlesztõeszközt választottam, melynek elõnye a többi, formális nyelvekre írt fejlesztõi környezethez [17] képest nem csak a nagymértékû alkalmazása (közel 700 cég több, mint 6000 fejlesztõje használja fõleg a telekommunikációs szektorban), hanem ennek az oka: az a tulajdonsága, hogy a teljes életciklus lefedéséhez szükséges formális nyelvek implementációit integrálja. Segítségével mind grafikusan, mind szöveges módban elkészíthetjük a tervezõi-fejlesztõi részt SDL nyelven, ábrázolhatjuk a kommunikációt dinamikusan MSC-ben - mindezen diagramszerkesztések interaktívan történnek - majd a tervezés validálásához automatikus forráskód elõállítására, a verifikációhoz tesztesetek generálására és szimulációjára is lehetõséget ad, melynek sikere esetén a futtatható kód automatikusan képezhetõ vele.

A Bluetooth L2CAP protokollelemzésének és formális leírásának bemutatása

A rendszerkövetelmények meghatározása, protokollelemzés

A réteg megvalósítása során az állapotok és az állapotátmenetet kiváltó PDU-k sorbavételének alapjául a SIG oldalán található és onnan letölthetõ specifikációt vettem alapul. A kommunikáció felépítése, folyamata, lebontása a master-slave viszony alapján történik, és a pikohálózat mastere kezdeményezi. A specifikáció alapján a következõ állapotok fordulnak elõ a rendszer mûködése során:

Closed: master- és slave-oldali állapot is lehet, a kapcsolat zárva van
W4_L2CAP_Connect_Rsp: ezt az állapotot csak a master veheti fel, miután elküldte a kapcsolatfelépítés kérésére vonatkozó jelzését a slave felé és annak válaszára vár
W4_L2CA_Connect_Rsp: csak a slave-re jellemzõ állapot, felsõbb rétege felé küldött kapcsolatfelépítési kérelem bejelentése után annak válaszára vár
Config: a master és a slave is felveheti, sikeres kapcsolatfelépítés után, vagy a kommunikáció során a csatornatulajdonságokban való megegyezésre szolgáló állapot
Open: a csatornatulajdonságok sikeres megállapítása után a kommunikáció lefolyását szolgáló, mindkét fél által felvehetõ állapot
W4_L2CAP_Disconnect_Rsp: csak a mater által felvehetõ állapot, kapcsolatbontási kérelmének a slave felé történõ elküldése után jut ide, és vár annak válaszára
W4_L2CA_Disconnect_Rsp: csak a slave veheti fel, miután a mastertõl kapcsolatbontási kérelem érkezett számára, felsõbb rétegének bejelentést küld arról, ebbe az állapotba tér át és vár a felette elhelyezkedõ réteg válaszára

A specifikációból megismerhetõ állapotok, szolgálati primitívek és PDU-k segítségével állítottam elõ az állapotátmeneti táblázatot melynek 58 sorából ide egyet emeltem ki, majd rajzoltam fel az állapotátmeneti gráfot (2. ábra), melyben mind a master, mind a slave viselkedése egyszerre van ábrázolva.

No	Esemény	Állapot 1.	Akció	Állapot 2.
38.	L2CA_DisconnectReq	Open	L2CAP_DisconnectReq	W4_L2CAP_Disconnect_Rsp

2. ábra: A Bluetooth L2CAP rétegének állapotátmeneti gráfja

Ezen ábrázolásmód segítségével megismerhetjük a rendszer viselkedését abból a szempontból, hogy adott állapotban megfelelõ bemenet hatására milyen akciók történnek és milyen állapotba történik az átmenet, illetve a gráfnak nagy hasznát vesszük az elemzés és a specifikáció validálása során. Ugyanakkor - fõleg nagyobb rendszerek esetén - zsúfolt és áttekinthetetlen. Szemben az SDL leírásával, ahol lehetõség van a redszer hierarchikus teljes mélységû leírására, így a legfelsõ hierarchiaszinten csak a legfontosabb rendszerjellegû információk vannak kiemelve, és egyre mélyebbre haladva egyre speciálisabb, pontosabb ábrázoláshoz jutunk.

Az L2CAP protokoll formális leírásának elkészítése

Az SDL leírás hierarchikusan épül fel. A hierarciaszintek meghatározásához a rendszerspecifikációt vettem alapul, így legcélszerûbb a legfelsõ szinten a két kapcsolatban lévõ L2CAP réteget, a köztük és a környezetükkel zajló kommunikációt ábrázolni. A következõ szinten az egyes L2CAP rétegeken belül zajló processzek közti kölcsönhatást ábrázolom, jelen esetben rétegenként egy-egy processz szerepel, ezek mûködését a legalsó, processz-szintû leírás hivatott bemutatni.

Legfelsõ szinten a rendszerszintû leírás helyezkedik el a kommunikáló felek, azaz a két Bluetooth eszköz L2CAP rétege, az általuk használt jelek, valamint az információcserét végzõ egyedek közötti, FIFO elven mûködõ csatornák ábrázolásával. Esetünkben a 3. ábra jól mutatja a rendszerszintû két elemet (master = L2CAP_Ini, slave = L2CAP_Resp), a közöttük zajló kommunikációban használt PDU-kat, valamint a kommunikációs csatornákat.

3. ábra: Az L2CAP protokoll rendszerszintû leírásának a kommunikáló feleket ábrázoló része

Az alkalmazott jelek a megfelelõ rövidítései a protokoll bemutatása alapján megismert funkcióknak, kivételt csak három jel jelenthet: az RTX (Response Timeout eXpired), valamint az ERTX (Extended Response Timeout eXpired) idõzítõ lejárta esetén figyelmeztet (az ERTX az RTX lejárta után esetlegesen megadható hosszabb idejû idõzítést tesz lehetõvé függõ válasz – Pnd esetén), míg a QoSViolationInd a szolgáltatás elvárt minõségének (Quality of Service) megsértését jelenti be.

A követezõ hierarchiaszinten a két fõszereplõt (master és slave L2CAP rétege) tovább bontva a blokkszintû leírás processz-kölcsönhatásait adom meg, mely az egyed belsõ felépítését, a magába foglalt funkcionális egységeket (processz) és azok kommunikációs útvonalait, az adatcserére használt jeleket mutatja be. Példaként az L2CAP_Resp blokkdiagrammját nézzük meg:

4. ábra: Az L2CAP protokoll blokkszintû leírásának részlete

Az ábra jól szemlélteti, hogy a blokk egyetlen processzt tartalmaz. Megfigyelhetõek a kommunikációhoz használt, FIFO elven mûködõ jelutak (C6,C7), azok kapcsolata a rendszerszinten ábrázolt csatornákkal, valamint a rajtuk szállított jelek típusa és irányítottsága.

Minden processz egy különálló véges automatát jelent, melyek egymással kommunikálva alkotják a tényleges rendszert. Az SDL teljes mélységû leírásra nyújtott lehetõsége a processzek definiálására, szerkezeteinek ábrázolására is módot ad, ennek segítségével a mûködés menete, folyamata is megjeleníthetõ. Az automaták viselkedésének formális leírása viselkedés-gráffal adható meg, melynek grafikus leírásában a különbözõ rajzos elemek más-más funkciót jelentenek. Ezen a szinten ábrázolom az L2CAP rétegek belsõ viselkedését (jelek fogadása, küldése, akciók és állapotátmenetek), a réteg jellemzõinél leírt szolgáltatások megvalósításának módját. A következõkben nézzük át a protokoll SDL-leírásának egy olyan részletét, melyben minden elõforduló elem, viselkedési forma megtalálható.

5. ábra: Az L2CAP protokoll processzintû leírásának részlete

A processz leírásánál egy szövegdobozban definiálom a használt változókat. Az n az ismétlések számát adja meg, melynek maximálisan megengedett értéke a kapcsolat bontása elõtt implementációfüggõ; p az idõzítõ beállítása esetén használt idõintervallum nagysága, t pedig a timert jelenti. A kiemelt részlet a slave W4_L2CA_Connect_Rsp állapotból kiinduló lehetõségeit ábrázolja.

Amennyiben a mastertõl a kapcsolat bontását kérõ L2CAP_DisconnectReq PDU-t kap, a felsõbb rétegnek ezt jelenti L2CA_DisconnectInd szolgálati primitív segítségével, majd beállítva az idõzítõt a kapcsolat bontását megelõzõ W4_L2CA_Disconnect_Rsp állapotba megy át.

Másik bemenetként kapott jel a felsõbb rétegtõl indított, a kapcsolat elfogadásáról szóló válasz lehet (L2CA_ConnectRsp), ennek megérkezésekor törli az idõzítõt, a masternek elküldi a kapcsolatkérés sikerérõl szóló L2CAP_ConnectRsp PDU-t, majd, amennyiben a bemeneti csatornájáról le tudta venni (akár korábbi mentésként) a mastertõl érkezett csatornakonfigurációs kérést (L2CAP_ConfigReq), ezt jelenti a felsõbb rétegnek a számlálót 1-re állítva és az idõzítõt is aktiválva. Ezután a Config állapotba kerül.

A kivitelezés során a mastertõl kapott konfigurációkérés kezelésével akadtak problémák. Elsõ lépésben a Config állapotba történõ átmenetet már a masternek küldött kapcsolatfelépítési sikerrõl szóló PDU továbbítása után éreztem jogosnak, a csatornabeállításra irányuló kérés megérkezése elõtt. Ugyanakkor abban az esetben a beérkezõ kérésrõl az L2CAP protokoll értesíti a felette elhelyezkedõ réteget, és azon a ponton várnia kell a válaszra, ami számos variációt hordoz magában. Itt, a várakozási ponton egy állapotnak feltétlen kell lennie, azonban a specifikáció nem szól több állapotról. Ezért a Config állapotba lépéskor kell a slave-nek ezekre a jelekre várnia, így a kapcsolatfelépítés sikerérõl történõ tájékoztatás után még egy bemenõ jel (a mastertõl érkezõ konfigurációkérés) feldolgozása szükséges az állapotátmenet elõtt: a konfigurációkérés lementésre kerül a csatornáról és amint megkapta a slave, a fent említett reakciója után megtörténik az állapotátmenet.

6. ábra: Az L2CAP protokoll processzintû leírásának részlete

A W4_L2CA_Connect_Rsp állapotban érkezhet a kapcsolat felépítésérõl olyan visszajelzés is, mely bár pozitív, de további feldolgozás szükségességérõl számol be (L2CA_ConnectRspPnd), ekkor errõl értesíti a slave a mastert, és nem változtat állapotot.

Amennyiben az L2CAP protokoll a felette levõ rétegtõl negatív választ kap a kapcsolatfelépítésre (L2CA_ConnectRspNeg), ezt tudatja a masterrel, és amennyiben nem érte el az újraküldések maximális számát, növeli a számlálót, beállítja az idõzítõt a következõ kérés megfelelõ idõn belül érkezése érdekében és marad a várakozó állapotban. Ellenkezõ esetben törli az idõzítõt és Closed állapotba megy át.

Ugyanez a két eshetõség van abban az esetben is, ha az idõzítõ lejár válasz nélkül.

A fentiekben csak egy állapotból történõ átmeneteket tekintettünk át, a teljes LCAP_RespPr processz leírása számos oldalon folytatódik. Hasonlóan meg kell adni az LCAP_Ini blokk és ennek processzeinek a leírását (lásd melléklet) és megkapjuk a teljes protokoll formális leírását. Bonyolult rendszerek esetén a jobb áttekinthetõség kedvéért további hierarchiaszinteket különíthetünk el a blokkszintet újabb blokkszintre bontva. Az ábrázolásban a funkcionalitást figyelembe véve jól átgondolt csoportosításokkal a nagy rendszerek esetén is jól kezelhetõ ábrázolásra van lehetõségünk az SDL segítségével.

Összefoglalás

A vezetéknélküli rövidtávú jelátvitel egyik legígéretesebb technológiájának, a rádiós átvitelt megvalósító Bluetoothnak az L2CAP protokollját jellemeztem, elemeztem, terveztem meg és a rendszer teljes mélységû leírását lehetõvé tévõ és számos elõnnyel rendelkezõ SDL specifikáló és leíró nyelv segítségével valósítottam meg a technológiát kifejlesztõ SIG csoport által prezentált specifikáció alapján.

Az L2CAP réteg funkcióival, szolgálatatásaival, azoknak az egész Bluetooth eszközben betöltött szerepével történõ megismerkedés, a protokoll elemzése után a SIG dokumentációja alapján terveztem meg a protokoll állapotátmeneti diagrammját. Ebbõl a funkciók csoportosításával, a rendszer hierarchiába rendezésével, a jelek által kiváltott akciók beleintegrálásával valósítottam meg az L2CAP protokollt SDL nyelven.

A további fejlesztésekhez ez alapot ad a rendszer futtatható kódban történõ implementálásához számos alkalmazás esetére, mivel az SDL absztrakt adattípusa megengedi, hogy a dinamikus viselkedés specifikálása után adjunk meg adatszerkezeteket teljes mélységben, melyek az egyes felhasználási esetekben különbözõek lehetnek.

Irodalomjegyzék

[1] http://www.cstack.com

[2] Puneet Gupta: Short-Range Wireless Connectivity: A Complementary Comparison

http://www.wirelessdevnet.com/channels/bluetooth/features/bluetooth_irda.html

[3] Dave Suvak: IrDA and Bluetooth: A Complementary Comparison

2000, Extended Systems, Inc.

http://www.extendedsystems.com/NR/rdonlyres/C7AD732D-C75E-11D4-87680001026

36F10/ir_bt_compare.pdf

[4] http://www.irda.org

[5] http://www.bluetooth.com/

[6] http://www.irda.org/standards/pubs/IrOBEX12.pdf

[7] http://www.brainboxes.com/index.html?support/index.html~mainFrame

[8] http://www.palowireless.com/bluetooth/products.asp

[9] http://www.sonyericssonmobile.com/bluetoothheadset/

[10] http://www.idg.net/idgns/2000/12/07/BluetoothMayHelpDisabledPeopleUse.shtml

[11] http://www.palowireless.com/infotooth/knowbase/companies/65.asp

[12] http://www.palowireless.com/infotooth/tutorial.asp

[13] http://www.xilinx.com/esp/bluetooth/pdf_files/bt_comp_bb_assp.pps

[14] http://www.etsi.org

[15] Harmatné Medve Anna, Dr. Tarnay Katalin:

A formális nyelvek szerepe a távközlési szoftverek fejlesztésében

[16] Fülöp Zoltán: Formális nyelvek és szintaktikus elemzésük

Polygon, 1999

[17] http://www.sdl-forum.org

Melléklet

Az elõzõekben és a mellékletben bemutatott ábrákat a Telelogic Tau 4.1 grafikus fejlesztõi környezetben szerkesztettem. Az alábbiakban a cikkben elemzett Initiator-oldali funkciókat megvalósító és be nem mutatott L2CAP_Ini block, illetve processz-szintû SDL-diagramok következnek.