Tekintsük át először röviden a Bluetooth-rendszer elemeit és célját. A rendszer alapegysége a pikohálózat (piconet), mely egy mester (master) csomópontból és legfeljebb hét darab, 10 méteres távolságon belül levő aktív szolga (slave) csomópontból áll. Ugyanabban a (nagyméretű) helységben több pikohálózat is lehet egyszerre, sőt egy híd csomópont – amely több pikohálózatban is részt vesz – révén azok össze is köthetők, amint az a 4.34. ábrán is látható. Az egymással összekötött pikohálózatokat szórt hálózatnak (scatternet) is nevezik.

4.34. ábra - Két pikohálózat összekapcsolásával egy szórt hálózatot kapunk

A pikohálózat hét aktív szolga csomópontja mellett legfeljebb 255 várakozó (parked) csomópont lehet a hálózatban. Ezek olyan eszközök, melyeket a mester alacsony teljesítményű állapotba vitt, hogy csökkentse az akkumulátoraik igénybevételét. Várakozó állapotban egy eszköz semmit sem tehet, leszámítva a mester aktivációs vagy jelzőfény jelére való válaszadást. Két köztes teljesítményállapot, a tartás (hold) és a szimatolás (sniff) szintén létezik, de ezekkel most nem foglalkozunk.

A mester/szolga felépítést az indokolja, hogy a tervezők 5 dollár alatti áron szerették volna megvalósítani egy komplett Bluetooth-lapka (chip) kivitelezését. Ennek a döntésnek az a következménye, hogy a szolgák meglehetősen buták, és lényegében mindig csak azt teszik, amire a mester utasítja őket. A pikohálózat voltaképpen egy központosított TDM-rendszer, melyben a mester vezérli az órát, és eldönti, hogy melyik eszköz melyik időszeletben kommunikálhat. A kommunikáció mindig csak a mester és egy szolga között folyhat; a szolgák közvetlenül nem érintkezhetnek egymással.

A hálózati protokollok többnyire csak csatornákat adnak a kommunikáló entitások számára, és az alkalmazás tervezőire bízzák, hogy mire használják azokat. A 802.11 például nem határozza meg, hogy mit kell csinálniuk a felhasználóknak a hordozható számítógépeiken: e-leveleket olvasni, a weben szörfölni vagy éppen valami mást. A Bluetooth ellenben meghatároz konkrét támogatandó alkalmazásokat, és mindegyik számára külön protokollkészletet biztosít. A könyv írásának időpontjában 25 alkalmazás van, melyeket profilnak (profile) is neveznek. Sajnos ez a megközelítés nagyon nagyfokú bonyolultsághoz vezet. Ennek a részletezésétől mi most eltekintünk, de vetünk egy pillantást ezekre a profilokra, hogy jobban megértsük, hogy mit akar véghezvinni a Bluetooth SIG.

A profilok közül hatot különböző audio- és videoalkalmazásokra készítettek. Például, az interkom profil lehetővé teszi két telefon walkie-talkie-szerű összekapcsolását. A fejhallgató (headset) és a kéz nélküli (hands-free) profilok beszédhang kommunikációt biztosítanak a fejhallgató és a bázisállomása között, és kéz nélküli telefóniára használható például autóvezetés közben. Más profilok jó minőségű beszéd- és videofolyam átvitelére valók, mondjuk egy hordozható zenelejátszóról a fejhallgatókra vagy digitális kameráról tv-re.

Az emberi interfészeszköz (human interface device) profilja billentyűzetek és egerek számítógéphez csatlakozására valók. Más profilok arra szolgálnak, hogy egy mobiltelefon vagy másmilyen számítógép fogadhasson képeket fényképezőgéptől vagy küldhessen képeket nyomtatóra. Érdekesebb lehet az a profil, amellyel a mobiltelefont egy (Bluetooth-képes) tévé távirányítójaként lehet használni.

Megint más profilok lehetővé teszik egy hálózat kiépítését. A személyi hálózatok (personal area network) profilja a Bluetooth-eszközöknek nyújt lehetőséget, hogy ad hoc hálózatot építsenek vagy távolról elérjenek egy másik hálózatot, mint például egy 802.11-es hálózatot egy hozzáférési ponton keresztül. Az egész projektet eredetileg betárcsázós (dial-up) profil motiválta. Ez teszi lehetővé, hogy egy számítógép egy beépített modemet tartalmazó mobiltelefonhoz vezetékek használata nélkül kapcsolódjon.

Felsőbb rétegbeli információcserélő profilokat is definiáltak. A szinkronizációs profil arra szolgál, hogy egy mobiltelefonba át lehessen vinni az asztali számítógép adatait, mielőtt az elhagyja a lakást, majd visszatölteni az új adatokat hazaérkezéskor.

A többi profilt nem tárgyaljuk, de azt meg kell jegyeznünk még, hogy van néhány profil, amelyekre mintegy építőkockaként más profilokat építettek. Az alap hozzáférés (generic access) profilra épül az összes többi profil, mert ez nyújt lehetőséget biztonságos kapcsolatok felépítésére és karbantartására a mester és a szolgák között. Más alapprofilok objektumok kicserélésének és audio/video átvitel alapjait határozzák meg. A segédprofilokat széleskörűen használják olyan feladatokhoz, mint amilyen a soros vonal emulálása, ami különösen fontos sok hagyományos alkalmazásnál.

Vajon tényleg szükség volt arra, hogy ezeket az alkalmazásokat részletezzék, és külön protokollkészletet készítsenek mindegyikhez? Valószínűleg nem, de a szabvány különböző részeit több különböző munkacsoport dolgozta ki, mindegyik csak a saját konkrét problémájával foglalkozott, és egy saját profilt hozott létre. Vehetjük úgy is, hogy Conway törvénye lépett működésbe. (A Datamation magazin 1968. áprilisi számában írta le Melvin Conway azt a megfigyelését, hogy ha n embert bízunk meg egy fordítóprogram megírásával, akkor egy n-menetes fordítót kapunk; vagy még általánosabban fogalmazva: egy szoftver felépítése tükrözi annak a csoportnak a felépítését, amely létrehozta azt.) Minden bizonnyal két protokoll is elég lett volna a 25 helyett: egy az állományátvitel és egy a folyamszerű (streaming) valós idejű kommunikáció számára.

A Bluetooth-szabványnak számos protokollja van, melyek laza rétegeket alkotnak, amint azt a 4.35. ábra mutatja. Az első megfigyelés, amit meg kell tennünk, hogy a felépítése nem követi sem az OSI-t, sem a TCP/IP-t, sem a 802-t, sem bármilyen más modellt.

4.35. ábra - A Bluetooth-protokoll architektúrája

Legalul van a fizikai rádiós réteg, ami nagyjából megfelel az OSI és a 802-es modellek fizikai rétegének. Ez a rádiós átvitellel és a modulációval foglalkozik. Itt az elgondolások jó része azzal a céllal kapcsolatos, hogy a rendszert minél olcsóbbá tegyék, vagyis hogy tömegtermelésben lehessen előállítani.

A kapcsolatvezérlő (vagy alapsávi réteg) valamelyest a MAC-alréteghez hasonlatos, de a fizikai rétegből is tartalmaz elemeket. Azzal foglalkozik, hogy a mester hogyan vezérli az időszeleteket, és hogy ezeket az időszeleteket hogyan csoportosítják keretekbe.

Ezután két protokoll következik, amelyek a kapcsolatvezérlő protokollt használják. A kapcsolatmenedzser az eszközök közötti logikai csatornák kiépítését kezeli, beleértve a teljesítménygazdálkodást, a párosítást és titkosítást, valamint a szolgáltatásminőséget is. Ez még a gazdagép–vezérlő interfész (Host Controller Interface) alatt fekszik. Ez az interfész a megvalósítás könnyítésére való: tipikusan az interfész alatt elhelyezkedő protokollokat a Bluetooth-lapkán valósítják meg, és a felette elhelyezkedő protokollokat az eszközön valósítják meg, amely a Bluetooth-lapka (chip) gazdagépe.

A kapcsolati protokoll az interfész felett az L2CAP (Logical Link Control Adaptation Protocol – logikai kapcsolatvezérlés adaptációs protokollja) helyezkedik el. Ez változó hosszúságú üzeneteket helyez keretekbe és szükség esetén megbízhatóságot is nyújt. Sok protokoll használja az L2CAP-ot, mint az a két hasznos protokoll, amit az ábrán megjelenítettünk. A szolgáltatás-felfedezés (Service Discovery) protokoll a hálózaton elérhető szolgáltatás felderítésére használatos. Az RFcomm (Radio Frequency Communication – rádiófrekvenciás kommunikáció) protokoll azt a szabványos soros portot helyettesíti, mely a PC-ket köti össze a billentyűzettel, egérrel, modemmel és más eszközökkel.

A legfelső rétegben vannak az alkalmazások. A profilokat függőleges dobozok képviselik, mert közülük mindegyik meghatározza a protokollkészlet egy szeletét egy bizonyos felhasználásra. Az egyes profilok, mint például a fejhallgató profilja, rendszerint csak az adott alkalmazás számára szükséges protokollokat tartalmazzák, semmi mást. Például a profilok magukba foglalhatják az L2CAP-ot, ha csomagokat akarnak küldeni, de ki is hagyhatják, ha csak egy stabil hangmintafolyamuk van.

A következő szakaszokban a Bluetooth rádiós rétegét vesszük szemügyre, illetve a különböző kapcsolati protokollokat, mivel ezek nagyjából megfelelnek más, korábban vizsgált protokollkészletek fizikai és MAC-alrétegének.

A rádiós réteg a biteket szállítja a mestertől a szolgáig vagy fordítva. Ez egy kis teljesítményű rendszer, 10 méteres hatósugárral, ugyanabban a 2,4 GHz-es ISM-sávban, mint a 802.11. A sáv 79 darab, egyenként 1 MHz-es csatornára van osztva. Hogy más hálózatokkal együtt tudjon élni az ISM-sávban, frekvenciaugrásos szórtspektrumot használ. Lehet akár 1600 ugrás másodpercenként az időszeletek felett 625 s-os tartózkodási idővel (dwell time). A pikohálózat összes csomópontja – követve a résidőzítést és a mester által diktált álvéletlen ugrási sorozatot – egyszerre végzi a frekvenciaugrásokat.

Sajnos az derült ki, hogy a Bluetooth korai verziói és a 802.11 annyira zavarták egymást, hogy tönkretették egymás átviteleit. Néhány cég a Bluetooth betiltásával válaszolt erre, de végül is kitaláltak egy műszaki megoldást, mégpedig azt, hogy a Bluetooth-nak úgy kell alakítania az ugrási sorozatát, hogy kihagyja azokat a csatornákat, ahol van más rádiófrekvenciás jel. Ez a folyamat csökkenti a káros zavarást, és adaptív frekvenciaugrásnak (Adaptive Frequency Hopping) nevezik.

Három modulációs eljárást használnak a bitek csatornán való átvitelére. Az alapvető modulációs eljárásként frekvenciabillentyűzést alkalmaznak 1 bites szimbólumok mikroszekundumonkénti átvitelére, ami kiadja a bruttó 1 Mb/s-os adatsebességet. Megnövelt sebességeket vezettek be a Bluetooth 2.0 verziójánál. Ezek a sebességek fázisbillentyűzést használnak szimbólumonkénti 2 vagy 3 bit küldésére, ami bruttó 2 vagy 3 Mb/s sebességet jelent. A megnövelt sebességeket csak a keretek adatrészében használják.

A kapcsolatvezérlési (vagy alapsávi) réteg az, ami a Bluetooth-ban leginkább hasonlít a MAC-alrétegre. Ez keretekbe rendezi a nyers bitfolyamot, és definiálja a legfontosabb formátumokat. Legegyszerűbb formájában az egyes pikohálózatokban lévő mesterek 625 s-os időszeletek sorozatát határozzák meg, ahol a mesterek adásai a páros, a szolgák adásai pedig a páratlan időszeletekben kezdődnek. Ez a séma a hagyományos időosztásos nyalábolás: a mesterek kapják meg az időszeletek egyik felét, a szolgák pedig a másikat. A keretek hossza 1, 3 vagy 5 időszelet lehet. Minden keretnek van többleteleme, mely 126 bitből áll a hozzáférési kód és a fejrész számára, plusz ugrásonként 250–260 s beállási időből (settling time), hogy az olcsó rádiós áramkörök stabilizálódhassanak. Annak érdekében, hogy a keret felhasználói adata megbízható maradjon, titkosítható egy kulccsal, amelyet a mester és a szolga összekapcsolódásakor választanak ki. Ugrások csak a keretek között történnek, nem pedig egy keret alatt. Ezek eredményeként egy 5 időszeletes keret sokkal hatékonyabb, mint egy 1 időszeletes keret, mert a többletelem állandó, de több adat került elküldésre.

A kapcsolatmenedzser protokoll egy kapcsolatnak (link) nevezett logikai csatornát állít fel, hogy kereteket vigyen át a mester és a szolga eszközök között, amelyek felfedezték egymást. Ezután egy párosítási folyamat következik, hogy mielőtt a csatornát használják, megbizonyosodjanak arról, hogy a két eszköznek megengedett az egymással való kommunikáció. A régi párosítási módszer alapján mindkét eszközt ugyanazzal a négy számjegyű PIN-számmal (Personal Identification Number – személyi azonosító szám) kell felkonfigurálni. Az egyező PIN-számok alapján ismerte volna fel egy eszköz, hogy a megfelelő távoli eszközhöz csatlakozik. Fantáziátlan felhasználók és eszközök olyan alap PIN-számokat használtak, mint a „0000” és az „1234”, ami azt jelentette, hogy a gyakorlatban ez a módszer nagyon kis biztonságot nyújtott.

Az új, egyszerű, biztonságos párosítási módszer lehetővé teszi, hogy a felhasználók megerősítsék azt, hogy mindkét eszköz ugyanazt a jelszót használja, vagy hogy megfigyeljék az egyik eszközön a jelszót, és bevigyék a másikba. Ez a módszer biztonságosabb, mert a felhasználóknak nem kell választaniuk vagy beállítaniuk egy jelszót. Nekik csupán egy hosszabb, az eszköz által létrehozott jelszót kell megerősíteniük. Természetesen ez nem használható olyan korlátozott be- és kiviteli képességű eszközökön, mint egy fejhallgató.

Amint a párosítás megtörtént, a kapcsolatmenedzser protokoll felépíti az adatkapcsolatot. Felhasználói adatok szállítására két fő kapcsolattípus létezik. Az első az SCO-kapcsolat (Synchronous Connection Oriented – szinkron összeköttetés-alapú). Ezt valós idejű adatok esetén, például telefonos kapcsolatoknál használják. Ehhez a kapcsolattípushoz mindkét irányban egy rögzített időszeletet rendelnek. Egy szolgának legfeljebb három SCO-kapcsolata lehet a mesterével. Minden egyes SCO-kapcsolat egy 64 kb/s-os PCM-beszédcsatornát képes átvinni. Az SCO-kapcsolatok időérzékeny természetéből adódóan a rajtuk átküldött kereteket sosem küldik újra. Ehelyett a megbízhatóság növelése érdekében hibajavítás alkalmazható.

A másik lehetőség az ACL-kapcsolat (Asynchronous Connection-Less – aszinkron összeköttetés nélküli kapcsolat). Ezt a kapcsolattípust a szabálytalan időközönként érkező csomagkapcsolt adatokhoz használják. Az ACL-forgalom „best-effort” alapon bonyolódik, garanciák tehát nincsenek: a keretek elveszhetnek, ilyenkor esetleg újra kell adni azokat. Egy szolgának legfeljebb egy ACL-kapcsolata lehet a mesterével.

Azt ACL-kapcsolaton küldött adat az L2CAP-rétegen keresztül érkezik meg. Ennek a rétegnek négy fő funkciója van. Először is ez fogadja a maximum 64 KB-os csomagokat a felsőbb rétegektől, és azokat az átvitel céljából keretekre tördeli. A másik oldalon a keretekből újra csomagokat állít elő. Másodszor, több csomagforrás esetén ez a réteg kezeli a nyalábolást (multiplexing) és a nyalábbontást (demultiplexing). A csomagok újbóli összerakása után az L2CAP-réteg dönti el, hogy melyik felsőbb rétegbeli protokollnak – például az RFcomm-nak vagy a szolgáltatás-felfedezésnek – kell átadni azokat. Harmadszor, az L2CAP-réteg kezeli a hibaellenőrzést és az újraküldéseket. Ez észleli a hibákat és küldi újra a nem nyugtázott csomagokat. Végül, az L2CAP betartatja a több kapcsolat közötti szolgáltatásminőségi követelményeket is.

A Bluetooth többféle keretformátumot határoz meg, melyek közül a legfontosabbat két változatban a 4.36. ábra mutatja be. Ez egy hozzáférési kóddal kezdődik, amely általában a mestert azonosítja, így az egyszerre két mester adáskörzetében tartózkodó szolgák tudni fogják, hogy melyik forgalom honnan származik. Ezt egy 54 bites fejrész követi, ami tipikus MAC-alrétegbeli mezőket tartalmaz. Ha a keretet alapsebességgel küldik, akkor ezután jön az adatmező, amely maximum 2744 bit hosszúságú öt időszeletes átvitel esetén. Ugyanez a formátum érvényes akkor is, ha csak egy időszeletet használunk, de ekkor az adatmező csak 240 bites.

4.36. ábra - Egy jellegzetes Bluetooth-adatkeret alapsebesség (fölül) és megnövelt sebesség (alul) esetén

Ha a keretet megnövelt sebességgel küldik, akkor az adatrészbe 2-szer vagy 3-szor annyi bit fér bele, mert minden szimbólum 2 vagy 3 bitet szállít 1 bit helyett. Ezeket az adatokat megelőzi egy védőmező és egy szinkronizációs minta, amit a gyorsabb sebességre váltásra használnak. Azaz, a hozzáférési kód és a fejrész alapsebességgel halad, és csak az adatmező halad gyorsabban. A megnövelt sebességű keretek egy rövid farokrésszel végződnek.

Vessünk egy pillantást a közös fejrészre. A Cím (Address) mező a nyolc aktív eszköz közül azonosítja azt, amelyiknek a keretet szánták. A Típus (Type) mező azonosítja a keret típusát (ACL, SCP, lekérdezés vagy nulla) és az adatmezőben használt hibajavítást, valamint megadja, hogy hány időszeletre terjed ki a keret. A Folyam (Flow) bitet a szolga állítja be, ha a puffere megtelt és már nem tud több adatot fogadni. Ez a bit a forgalomszabályozás egy primitív formáját hozza létre. A Nyugta (Acknowledgement) bit segítségével egy ACK-t ültetnek rá a keretre. A Sorszám (Sequence) bittel számozzák meg a kereteket az újraadások felismerése céljából. Azért elég ide mindössze 1 bit, mert a megáll-és-vár protokollt használják. Ezután következik a fejrész 8 bites Ellenőrző összege (Checksum). Az egész 18 bites fejrészt háromszor ismétlik meg, így jön ki a 4.36. ábrán látható 54 bites fejrész. A vételi oldalon egy egyszerű áramkör megvizsgálja az egyes bitek mindhárom másolatát. Ha ezek mind megegyeznek, a bitet elfogadják. Ha nem, a többség dönt. Ily módon 54 bites átviteli kapacitást használnak fel a 10 bites fejrész elküldésére. Ezt az indokolja, hogy zajos környezetben csak jókora redundancia segítségével lehet olcsó, kis teljesítményű (2,5 mW-os), csekély számítási kapacitású eszközökkel megbízható adatátvitelt megvalósítani.

Az ACL- és SCO-keretek adatmezejénél számos formátum használatos. Az alapsebességű SCO-keretek tanulmányozása egyszerű: az adatmező mindig 240 bites. Itt három különböző változatot definiáltak, ezek 80, 160 vagy 240 bites tényleges adatot tesznek lehetővé; a maradék a hibajavítást szolgálja. A legmegbízhatóbb változatnál (ahol 80 bites a tényleges adat), a tartalmat egyszerűen háromszor megismétlik, akárcsak a fejrésznél.

Kiszámolhatjuk ennek a keretnek a kapacitását. Mivel a szolga csak a páratlan időszeleteket használhatja, 800 időszeletet kaphat másodpercenként, éppúgy, mint a mester. 80 bites tényleges adat esetén a csatorna kapacitása mind a szolga, mind a mester részéről 64 kb/s. Ez a kapacitás pedig éppen elég egy duplex PCM-beszédcsatorna számára (ezért döntöttek a másodpercenkénti 1600 ugrás mellett). Azaz, hiába áll rendelkezésre 1 Mb/s átviteli kapacitás, egy tömörítetlen, 64 kb/s-os duplex beszédcsatorna teljesen telíti a pikohálózatot. A 13%-os hatékonyság az eredménye annak, hogy a kapacitás 41%-át beállási idővel, 20%-át fejrésszel és 26%-át ismétlő kódolással töltik. Ez a hiányosság emeli ki a megnövelt sebesség és a több mint 1 időszeletes keretek hasznát.

Sokkal többet is lehetne még mondani a Bluetooth-ról, de a könyv keretei ezt nem teszik lehetővé. Az érdeklődők számára a Bluetooth 4.0 specifikáció tartalmaz minden részletet.