Lista över Bluetooth-protokoll

Standarden för trådlöst datautbyte Bluetooth använder en mängd olika protokoll . Kärnprotokoll definieras av branschorganisationen Bluetooth SIG . Ytterligare protokoll har antagits från andra standardiseringsorgan. Den här artikeln ger en översikt över kärnprotokollen och de antagna protokoll som används ofta.

Bluetooth-protokollstacken är uppdelad i två delar: en "kontrollerstack" som innehåller det tidkritiska radiogränssnittet och en "värdstack" som hanterar data på hög nivå. Styrstacken implementeras i allmänhet i en billig kiselanordning som innehåller Bluetooth-radion och en mikroprocessor. Värdstacken implementeras vanligtvis som en del av ett operativsystem, eller som ett installerbart paket ovanpå ett operativsystem. För integrerade enheter som Bluetooth-headset kan värdstacken och kontrollerstacken köras på samma mikroprocessor för att minska massproduktionskostnaderna; detta är känt som ett värdlöst system.

Controller stack

Asynkron anslutning-mindre [logisk transport] (ACL)

Den normala typen av radiolänk som används för allmänna datapaket som använder ett polling TDMA -schema för att medla åtkomst. Den kan bära paket av flera typer, som kännetecknas av:

• längd (1, 3 eller 5 tidsluckor beroende på önskad nyttolaststorlek)
• Framåtriktad felkorrigering (valfritt minska datahastigheten till förmån för tillförlitlighet)
• modulering ( Enhanced Data Rate -paket tillåter upp till tredubbla datahastigheter genom att använda en annan RF-modulering för nyttolasten)

En anslutning måste uttryckligen upprättas och accepteras mellan två enheter innan paket kan överföras.

ACL-paket återsänds automatiskt om de inte bekräftas, vilket möjliggör korrigering av en radiolänk som är utsatt för störningar. För isokrona data kan antalet återsändningar begränsas av en spolningstimeout; men utan att använda L2PLAY-omsändnings- och flödeskontrollläge eller EL2CAP måste ett högre lager hantera paketförlusten.

ACL-länkar kopplas bort om det inte tas emot något under övervakningens timeoutperiod; standard timeout är 20 sekunder, men detta kan ändras av mastern.

Synchronous Connection-Oriented (SCO) länk

Den typ av radiolänk som används för röstdata. En SCO-länk är en uppsättning reserverade tidsluckor på en befintlig ACL-länk. Varje enhet sänder kodad röstdata i den reserverade tidsluckan. Det finns inga återsändningar, men vidarebefordran av felkorrigering kan valfritt tillämpas. SCO-paket kan skickas var 1:e, 2:e eller 3:e tidslucka.

Förbättrade SCO-länkar (eSCO) ger större flexibilitet när det gäller att sätta upp länkar: de kan använda omsändningar för att uppnå tillförlitlighet, möjliggöra ett större utbud av pakettyper och för större intervall mellan paket än SCO, vilket ökar radiotillgängligheten för andra länkar(.)

Link Management Protocol (LMP)

Används för kontroll av radiolänken mellan två enheter, highe, dmv, förfrågning av enhetsförmågor och effektkontroll. Implementerad på styrenheten.

Host Controller Interface (HCI)

Standardiserad kommunikation mellan värdstacken (t.ex. en PC eller mobiltelefon OS) och styrenheten (den integrerade Bluetooth-kretsen (IC)). Denna standard gör att värdstacken eller styrenhetens IC kan bytas ut med minimal anpassning.

Det finns flera HCI-transportlagerstandarder, som var och en använder olika hårdvarugränssnitt för att överföra samma kommando-, händelse- och datapaket. De vanligaste är USB (i datorer) och UART (i mobiltelefoner och handdatorer).

I Bluetooth-enheter med enkel funktionalitet (t.ex. headset) kan värdstacken och styrenheten implementeras på samma mikroprocessor. I det här fallet är HCI valfritt, även om det ofta implementeras som ett internt mjukvarugränssnitt.

Low Energy Link Layer (LE LL)

Detta är LMP-motsvarigheten för Bluetooth Low Energy (LE), men är enklare. Den är implementerad på styrenheten och hanterar reklam, skanning, anslutning och säkerhet från en låg nivå, nära hårdvarusynpunkt ur Bluetooth-perspektiv....

Värdstack

Logisk länkkontroll och anpassningsprotokoll (L2CAP)

L2CAP används inom Bluetooth-protokollstacken. Den skickar paket till antingen Host Controller Interface (HCI) eller, på ett värdlöst system, direkt till Link Manager/ACL-länken.

L2CAP:s funktioner inkluderar:

• Multiplexa data mellan olika högre lagerprotokoll.
• Segmentering och återmontering av paket.
• Tillhandahåller envägsöverföringshantering av multicast-data till en grupp andra Bluetooth-enheter.
• Kvalitetshantering (QoS) för protokoll med högre lager.

L2CAP används för att kommunicera över värd ACL-länken. Dess anslutning upprättas efter att ACL-länken har ställts in.

I basläget tillhandahåller L2CAP paket med en nyttolast som kan konfigureras upp till 64 kB, med 672 byte som standard MTU och 48 byte som minsta obligatoriska MTU som stöds. I återsändnings- och flödeskontrolllägen kan L2CAP konfigureras för tillförlitlig eller asynkron data per kanal genom att utföra återsändningar och CRC-kontroller. Tillförlitligheten i något av dessa lägen garanteras valfritt och/eller dessutom av det undre skiktet Bluetooth BDR/EDR luftgränssnitt genom att konfigurera antalet återsändningar och spolningstimeout (tid efter vilken radion kommer att spola paket). Sekvensering i ordning garanteras av det nedre lagret.

EL2CAP-specifikationen lägger till ett ytterligare förbättrat återsändningsläge (ERTM) till kärnspecifikationen, som är en förbättrad version av återsändnings- och flödeskontrolllägen. ERTM krävs när du använder en AMP (Alternate MAC/PHY), såsom 802.11abgn.

Bluetooth Network Encapsulation Protocol (BNEP)

BNEP används för att leverera nätverkspaket ovanpå L2CAP. Detta protokoll används av profilen (Personal Area Networking) . BNEP utför en liknande funktion som Subnetwork Access Protocol (SNAP) i trådlöst LAN.

I protokollstacken är BNEP bunden till L2CAP.

Radiofrekvenskommunikation (RFCOMM)

Bluetooth-protokollet RFCOMM är en enkel uppsättning transportprotokoll, gjorda ovanpå L2CAP-protokollet, som tillhandahåller emulerade RS-232 serieportar (upp till sextio samtidiga anslutningar till en Bluetooth-enhet åt gången). Protokollet är baserat på ETSI-standarden TS 07.10.

RFCOMM kallas ibland serieportemulering . Bluetooth seriell portprofil (SPP) baseras på detta protokoll.

RFCOMM tillhandahåller en enkel tillförlitlig dataström till användaren, liknande TCP. Den används direkt av många telefonirelaterade profiler som bärare för AT-kommandon, samt är ett transportlager för OBEX över Bluetooth.

Många Bluetooth-applikationer använder RFCOMM på grund av dess utbredda stöd och offentligt tillgängliga API på de flesta operativsystem. Dessutom kan applikationer som använde en seriell port för att kommunicera snabbt portas för att använda RFCOMM.

I protokollstacken är RFCOMM bunden till L2CAP.

Service Discovery Protocol (SDP)

Används för att låta enheter upptäcka vilka tjänster varandra stödjer och vilka parametrar som ska användas för att ansluta till dem. Till exempel, när du ansluter en mobiltelefon till ett Bluetooth-headset, kommer SDP att användas för att avgöra vilka Bluetooth-profiler som stöds av headsetet ( headsetprofil , handsfree-profil , avancerad ljuddistributionsprofil , etc.) och de protokollmultiplexerinställningar som behövs för att ansluta till var och en av dem. Varje tjänst identifieras av en Universally Unique Identifier (UUID), med officiella tjänster (Bluetooth-profiler) tilldelade en kortformad UUID (16 bitar istället för hela 128).

I protokollstacken är SDP bunden till L2CAP.

Telefonikontrollprotokoll (TCS)

Kallas även för telefonikontrollprotokollspecifikation binär (TCS binär)

Används för att ställa in och styra tal- och datasamtal mellan Bluetooth-enheter. Protokollet är baserat på ITU-T-standarden Q.931 , med bestämmelserna i bilaga D tillämpade, vilket gör endast de minsta ändringar som krävs för Bluetooth.

TCS används av profilerna intercom (ICP) och trådlös telefoni (CTP). Telefonkontrollprotokollspecifikationen kallas inte TCP, för att undvika förväxling med transmissionskontrollprotokoll (TCP) som används för Internetkommunikation.

Audio/video control transport protocol (AVCTP)

Används av fjärrkontrollprofilen för att överföra AV/C -kommandon över en L2CAP-kanal. Musikkontrollknapparna på ett stereoheadset använder detta protokoll för att styra musikspelaren.

I protokollstacken är AVCTP bunden till L2CAP.

Audio/video data transport protocol (AVDTP)

Används av den avancerade ljuddistributionsprofilen för att streama musik till stereoheadset över en L2CAP-kanal. Avsedd att användas av videodistributionsprofil.

I protokollstacken är AVDTP bunden till L2CAP.

Objektutbyte (OBEX)

Huvudartikel: OBEX

Objektutbyte (OBEX; även kallat IrOBEX ) är ett kommunikationsprotokoll som underlättar utbyte av binära objekt mellan enheter. Det underhålls av Infrared Data Association men har också antagits av Bluetooth Special Interest Group och SyncML- flygeln i Open Mobile Alliance (OMA).

I Bluetooth används OBEX för många profiler som kräver enkelt datautbyte (t.ex. objekt-push, filöverföring, grundläggande bildbehandling, grundläggande utskrift, telefonboksåtkomst, etc.).

Low Energy Attribute Protocol (ATT)

Liknar i omfattning SDP men speciellt anpassad och förenklad för Low Energy Bluetooth. Det tillåter en klient att läsa och/eller skriva vissa attribut som exponeras av servern på ett icke-komplext sätt som är vänligt med låg effekt.

I protokollstacken är ATT bunden till L2CAP.

Low Energy Security Manager Protocol (SMP)

Detta används av Bluetooth Low Energy-implementeringar för att para ihop och transportera specifik nyckeldistribution.

I protokollstacken är SMP bunden till L2CAP.

externa länkar

• Bluetooth.com - Datatransportarkitektur
• Oracle.com - Bluetooth-protokollstacköversikt med diagram (halvvägs ner på sidan)
• Katalog med Bluetooth-specifikationer