Czym jest BLE? Kluczowe różnice w porównaniu z klasycznym Bluetooth

Bluetooth i BLE w skrócie

Bluetooth to technologia bezprzewodowa krótkiego zasięgu przeznaczona do sieci osobistych: urządzenia komunikują się bezpośrednio na kilka metrów bez kabli. Używa się jej do słuchawek bezprzewodowych, klawiatur, zestawów samochodowych i przesyłu plików między bliskimi urządzeniami.

BLE to skrót od Bluetooth Low Energy. To odrębny tryb pod tą samą marką Bluetooth, zaprojektowany przede wszystkim dla małych, rzadkich porcji danych przy bardzo niskim zużyciu energii. Gdy klasyczny Bluetooth celuje w ciągłe strumienie danych (np. audio), BLE jest dostrojony do czujników i urządzeń, które muszą działać miesiącami lub latami na malutkich bateriach.

Obie technologie są określone przez Bluetooth SIG i dzielą części stosu oraz logo „Bluetooth”, ale technicznie BLE i klasyczny Bluetooth to nie to samo. Mają różne procedury radiowe, modele danych i są zoptymalizowane do innych zadań.

Typowe urządzenia BLE

Spotykasz technologię BLE na co dzień, często nie zdając sobie z tego sprawy:

• Opaski fitness i smartwatche
• Pas do pomiaru tętna i medyczne wearables
• Inteligentne zamki i tagi
• Beacony w sklepach lub na wydarzeniach
• Czujniki środowiskowe i inne węzły IoT

Na czym skupi się ten przewodnik

Ten artykuł wyjaśnia BLE vs klasyczny Bluetooth w praktyczny sposób: jak różnią się zachowaniem radiowym, zużyciem energii, zasięgiem, przepustowością, opóźnieniami, bezpieczeństwem i modelami danych (jak profile GATT). Zobaczysz, gdzie BLE błyszczy (czujniki IoT, wearables, beacony), a gdzie klasyczny Bluetooth nadal dominuje (audio, HID, niektóre akcesoria legacy), by móc wybrać odpowiednią technologię dla swojego projektu.

Dlaczego BLE powstał

Pierwotna misja Bluetooth: zastąpić kable

Wczesne wersje Bluetooth (1.x, 2.x, 3.0) były projektowane głównie jako bezprzewodowe zastępstwo dla krótkich kabli: zestawy słuchawkowe zamiast gniazda audio, klawiatury i myszy zamiast USB, przesył plików zamiast portów szeregowych.

To założenie obejmowało urządzenia z przyzwoitymi bateriami lub stałym zasilaniem. Telefony, laptopy i systemy samochodowe mogły pozwolić sobie na radio, które pozostawało połączone przez długi czas, strumieniując audio lub przesyłając duże pliki.

Problem z energią dla malutkich urządzeń

Gdy zaczęto wyobrażać sobie bezprzewodowe czujniki, wearables, beacony i urządzenia medyczne, profil energetyczny klasycznego Bluetooth stał się problemem.

Utrzymanie linku klasycznego Bluetooth wymaga częstych aktywności radiowych i stosunkowo rozbudowanego stosu protokołów. Dla smartwatcha, czujnika na ogniwo guzikowe czy czujki drzwi, która ma działać miesiącami lub latami, taki poziom zużycia jest po prostu za wysoki.

Istniały inne niskoprądowe rozwiązania radiowe (np. własnościowe łącza 2,4 GHz), ale brakowało im interoperacyjności i ekosystemu Bluetooth.

Bluetooth 4.0 i narodziny BLE

Bluetooth 4.0 wprowadził Bluetooth Low Energy (BLE) jako nowy tryb obok klasycznego Bluetooth, nie jako drobną poprawkę.

BLE zaprojektowano wokół innego założenia: wiele urządzeń musi tylko krótko się obudzić, wysłać lub odebrać małą porcję danych, a potem wrócić do snu. Pomyśl: „tętno 72 BPM”, „drzwi są otwarte” lub „temperatura 21,3 °C”, nie ciągłe audio.

Połączenia są lżejsze, reklamowanie jest efektywne, a radia mogą być wyłączone większość czasu.

Układy dual‑mode: najlepsze z obu światów

Nowoczesne układy Bluetooth często obsługują oba tryby. Smartfon może strumieniować audio przez klasyczny Bluetooth do słuchawek, a jednocześnie rozmawiać przez BLE z opaską fitness lub beaconem za pomocą jednego modułu radiowego.

Jak działa BLE na wysokim poziomie

BLE opiera się na krótkich, efektywnych wymianach małych pakietów, zamiast ciągłych strumieni o wysokiej przepustowości. Na wysokim poziomie działa w dwóch głównych fazach: odkrywanie (reklamowanie) i transfer danych (przez strukturalny model danych zwany GATT).

Reklamowanie i wykrywanie

Większość interakcji BLE zaczyna się od reklamowania. Urządzenie peryferyjne (np. czujnik lub beacon) okresowo wysyła małe pakiety broadcastowe na określonych kanałach radiowych. Te pakiety reklamowe:

• Informują, że urządzenie istnieje
• Opcjonalnie zawierają mały ładunek (ID, flagi lub kilka bajtów danych z czujnika)
• Wskazują, jak i czy centralny może się połączyć

Centralne urządzenie (zwykle telefon, tablet lub bramka) skanuje te pakiety. Gdy znajdzie interesujące peryferyjne, może albo tylko odczytać rozgłaszane dane (tryb bezpołączeniowy), albo zainicjować połączenie.

Tryb bezpołączeniowy vs połączeniowy

BLE wspiera:

• Tryb bezpołączeniowy (broadcast) – peryferia ciągle reklamują; centrale tylko nasłuchują. Dobre dla beaconów, telemetryki jednokierunkowej, wykrywania obecności.
• Tryb połączeniowy – centralny inicjuje link z jednym peryferyjnym. Wtedy wymieniają pakiety na zaplanowanych zdarzeniach, z potwierdzeniami i zabezpieczeniami.

GATT, serwisy i charakterystyki

Po nawiązaniu połączenia BLE używa Generic Attribute Profile (GATT) do strukturyzowanej wymiany danych. GATT definiuje:

• serwer (zazwyczaj peryferium) eksponujący dane
• klient (zazwyczaj centralny) czytający lub zapisujący te dane

Dane są zorganizowane w:

• Serwisy – grupowania według funkcji (np. Heart Rate, Battery)
• Charakterystyki – pojedyncze elementy danych w ramach serwisu

Każda charakterystyka może być czytana, zapisywana lub subskrybowana (notifications). Typowe wartości atrybutów BLE są małe, często od kilku bajtów do kilkudziesięciu bajtów. Zamiast przesyłać duże bloki, urządzenia wykonują wiele szybkich, celowanych transakcji: odczyty, zapisy i powiadomienia z zwięzłymi ładunkami specyficznymi dla aplikacji.

Klasyczny Bluetooth w prostych słowach

Klasyczny Bluetooth to pierwotna wersja standardu Bluetooth, zaprojektowana dla urządzeń potrzebujących stosunkowo stabilnego strumienia danych i mogących pozostawać połączonymi przez dłuższy czas. Jego celem jest zapewnienie niezawodnych, ciągłych łączy o wyższej przepustowości niż typowo oferuje BLE.

Gdy BLE skupia się na krótkich porcjach danych i długich okresach uśpienia, klasyczny Bluetooth zakłada, że radio będzie aktywne znacznie częściej. To czyni go lepszym do takich zadań jak audio czy wejścia w czasie rzeczywistym, ale oznacza też wyższe i bardziej stałe zużycie energii.

Klasyczny Bluetooth i BLE działają w paśmie ISM 2,4 GHz, ale stosują różne strategie wyżej. Klasyczny używa formy frequency hopping zoptymalizowanej pod kątem ciągłych połączeń i streamingu, podczas gdy BLE jest dostrojony do krótkich, efektywnych wymian.

Typowe profile klasycznego Bluetooth

Klasyczny Bluetooth definiuje wiele standardowych profili, aby urządzenia wiedziały, jak się ze sobą komunikować:

• A2DP – wysokiej jakości przesył audio (słuchawki, głośniki).
• HFP – Hands‑Free Profile dla połączeń w zestawach słuchawkowych i samochodach.
• HID – Human Interface Device, używany przez klawiatury, myszy i kontrolery.
• SPP – Serial Port Profile, emulujący port szeregowy przez Bluetooth.

Typowe zastosowania

Dzięki celom projektowym i profilom, klasyczny Bluetooth najlepiej nadaje się do:

• Strumieniowania muzyki i głosu (słuchawki, głośniki, systemy car‑audio).
• Klawiatur i myszy, które wysyłają częste zdarzenia wejścia.
• Kontrolerów gier, które potrzebują niskich opóźnień i stałej komunikacji.

Wszystkie te scenariusze zakładają urządzenie z relatywnie stabilnym zasilaniem (telefony, laptopy, systemy samochodowe), nie malutkie czujniki na baterie guzikowe.

Pod maską: różnice radiowe i przepływ danych

Modulacja, kanały i skakanie

Klasyczny Bluetooth (BR/EDR) i BLE dzielą pasmo 2,4 GHz, lecz dzielą je inaczej.

• Klasyczny Bluetooth

  • Używa 79 kanałów po 1 MHz (2.402–2.480 GHz).
  • Base Rate (BR): GFSK przy 1 Mb/s.
  • Enhanced Data Rate (EDR): π/4‑DQPSK (2 Mb/s) i 8DPSK (3 Mb/s).
  • Hopping po wszystkich 79 kanałach 1600 razy na sekundę przy pseudo‑losowej sekwencji.

• BLE

  • Używa 40 kanałów, każdy 2 MHz szeroki.
  • Oryginalne PHY: GFSK przy 1 Mb/s (LE 1M).
  • Opcjonalne PHY: 2 Mb/s (LE 2M) oraz coded PHY (długi zasięg, niższa efektywna przepustowość).
  • Hopping też występuje, ale po mniejszym zbiorze kanałów z innym algorytmem wyboru, upraszczającym niskoprądową pracę i współistnienie.

Szerokość kanałów i uproszczone opcje modulacji w BLE są zoptymalizowane pod niskie zużycie i krótkie porcje danych, a nie pod ciągły wysokoprzepustowy streaming.

Topologia połączeń i przepływ danych

• Klasyczny Bluetooth

  • Używa piconetów: jeden master i do siedmiu aktywnych slave'ów.
  • Możliwe są scatternety, ale wsparcie w produktach jest ograniczone.
  • Dane traktowane często jako stosunkowo ciągłe strumienie (np. audio, emulacja portu szeregowego).

• BLE

  • Używa prostszej topologii gwiazdy: jeden centralny, wiele peryferii.
  • Centralny może utrzymywać dziesiątki linków o niskim udziale czasu aktywnego.
  • Dane wymieniane są w krótkich zdarzeniach połączenia lub za pomocą pakietów reklamowych bez połączenia.

Przepustowość i opóźnienia

• Przepustowość BR/EDR (klasyczny)

  • Teoretycznie: do 3 Mb/s na PHY.
  • Praktyczny payload aplikacyjny: zwykle 1–2 Mb/s dla streamingu.
  • Opóźnienia dostrojone do ruchu ciągłego; ścieżki audio często osiągają dziesiątki milisekund end‑to‑end.

• Przepustowość BLE

  • LE 1M PHY teoretycznie: 1 Mb/s; praktyczny payload aplikacyjny często 0,1–0,8 Mb/s w zależności od MTU, interwału połączenia i stosu.
  • LE 2M może przybliżenie podwoić surową szybkość, ale wciąż obciążona jest narzutem protokołu.
  • Coded PHY daje dłuższy zasięg kosztem znacznie mniejszej przepustowości.
  • Latencja zależy od zdarzeń: przy 7.5 ms interwale połączenia jednopakietowe opóźnienie może wynosić kilka ms, ale tryby oszczędzania energii używają dłuższych interwałów, co zwiększa opóźnienie.

Ogólnie klasyczny lepiej nadaje się do stałych, wysokoprzepustowych, niskoopóźnieniowych strumieni, podczas gdy BLE jest dostrojony do krótkich, rzadkich porcji z możliwością manewrowania trade‑offem między opóźnieniem a energią.

Współistnienie na tym samym układzie lub telefonie

Większość telefonów i wiele modułów to dual‑mode: jeden front‑end RF i antena, współdzielone przez BR/EDR i BLE kontrolery.

W chipie:

• Jeden transceiver radiowy jest time‑sliced między klasycznym i BLE.
• Firmware kontrolera uruchamia dwa link layer'y, planując kiedy który może transmitować lub nasłuchiwać.
• Stos hosta (po stronie OS) udostępnia jedną tożsamość Bluetooth, podczas gdy wewnętrznie kieruje ruch do BR/EDR lub BLE.

Harmonogram zapewnia, że strumienie audio klasyczne dostają potrzebne terminy, a połączenia i reklamy BLE są wplatane w luki, dzięki czemu obie protokoły mogą działać równocześnie bez zakłóceń na warstwie aplikacji.

Porównanie zużycia energii i żywotności baterii

Największą przewagą BLE nad klasycznym Bluetooth jest to, ile czasu radio pozostaje wyłączone. Wszystko w protokole jest dostrojone do bardzo niskich współczynników zajętości: krótkie wybuchy aktywności oddzielone długimi okresami snu.

Dlaczego BLE oszczędza energię

Urządzenie BLE większość czasu spędza w głębokim śnie, budząc się tylko po to, by:

• Wysłać lub nasłuchać pakiet reklamowy
• Wymienić dane podczas krótkich zdarzeń połączenia

Każde z tych zdarzeń trwa typowo kilka milisekund. Pomiędzy nimi radio i większość MCU są wyłączone, pobierając mikroampery zamiast miliamperów.

Klasyczny Bluetooth natomiast utrzymuje aktywne połączenie z częstym pollingiem. Nawet gdy mało danych jest przesyłanych, radio budzi się często, więc średni prąd pozostaje znacznie wyższy.

Interwały reklamowe i tryby snu

Moc w BLE jest zdominowana przez częstotliwość budzeń:

• Interwał reklamowy: beacon może reklamować co 100 ms, 500 ms lub kilka sekund. Dłuższy interwał = rzadsze budzenia = dramatyczne obniżenie prądu średniego.
• Interwał połączenia: po sparowaniu urządzenia spotykają się w stałych odstępach (np. 7.5 ms–4 s). Każde spotkanie jest krótkie; pomiędzy nimi peryferium może spać.
• Stany snu: nowoczesne SoC BLE używają prądu głębokiego snu rzędu ~1–3 µA. Piki z radiem mogą wynosić 10–20 mA, ale trwają tylko kilka ms.

Przykład: jeśli urządzenie pobiera 15 mA przez 3 ms co 100 ms, współczynnik wypełnienia to 3%. Średnio to ~0.45 mA (450 µA). Jeśli interwał zwiększyć do 1 s, współczynnik spada do 0.3%, zmniejszając średni prąd 10×.

BLE vs klasyczny Bluetooth: pobór prądu

Przybliżone wartości (rzeczywiste zależą od sprzętu i ustawień):

• Słuchawki audio klasyczne: 20–30 mA podczas streamingu; nawet w trybie idle widać mA z powodu ciągłego utrzymania łącza.
• Czujnik BLE, okresowo łączony: 10–20 mA podczas krótkich zdarzeń, średnio dziesiątki do setek µA na dłuższą metę.
• Beacon BLE: często \u003c20–50 µA średnio przy umiarkowanym TX i 1 s interwałach reklamowych.

Ta różnica rzędu wielkości tłumaczy, dlaczego produkty klasyczne są zwykle ładowalne, a peryferia BLE często działają na bateriach guzikowych.

Co naprawdę decyduje o żywotności baterii

Dla BLE kluczowe parametry to:

• Interwał połączenia: dłuższe → mniej budzeń → niższy prąd średni, ale większe opóźnienia.
• Slave latency: pozwala peryferium pominąć niektóre zdarzenia połączenia, obniżając zużycie.
• MTU i fragmentacja danych: większe MTU pozwala przesłać więcej danych w jednym zdarzeniu, zmniejszając liczbę budzeń dla danej ilości danych.
• Poziom mocy nadawania: wyższa moc TX zwiększa prąd per zdarzenie, ale może pozwolić na dłuższe interwały lub mniej retransmisji.
• Stany zasilania MCU i czujników: często radio jest zoptymalizowane, podczas gdy MCU lub czujniki dominują budżet energetyczny. Krytyczne jest usypianie wszystkiego między zdarzeniami.

Ogniwa guzikowe, miesiące i lata pracy

Przy starannym dostrojeniu urządzenia BLE mogą działać długo na małych bateriach:

• Beacon na CR2032 (~220 mAh)

  • Średni prąd ~15 µA (niska moc TX, 1–2 s reklamowanie)
  • Teoretyczne życie: 220 mAh / 0.015 mA ≈ 14 600 godzin → 1.5–2 lata (w praktyce krócej z powodu upływu samoczynnego, temperatury i starzenia baterii).

• Czujnik środowiskowy na CR2477 (~1000 mAh)

  • Budzi się co minutę, robi pomiar, wysyła dane w krótkim połączeniu BLE
  • Starannie zaprojektowany średni prąd 20–30 µA jest realistyczny
  • Teoretyczne życie: 3–5 lat.

• Wearables (opaski fitness)

  • Wyższy współczynnik duty‑cycle przez częste aktualizacje i użycie wyświetlaczy
  • Zazwyczaj ładują się co kilka dni do kilku tygodni, a radio BLE jest często tylko częścią budżetu energetycznego (display, wibrator, czujniki mogą dominować).

Klasyczny Bluetooth ledwo osiągnie te czasy pracy na ogniwach guzikowych przy normalnym użytkowaniu. To niskoprądowy projekt BLE i agresywne uśpienia umożliwiają wielomiesięczną lub wieloletnią pracę w aplikacjach IoT.

Zasięg, przepustowość i kompromisy opóźnień

Zasięg w realnych środowiskach

Na papierze zarówno BLE, jak i klasyczny Bluetooth podają zasięgi 10 m do 100+ m. W praktyce zwykle obserwuje się:

• Wewnątrz budynków (biura, domy): 5–15 m niezawodnie dla obu
• Przestrzeń otwarta, widoczność: 30–50 m jest powszechne; więcej możliwe przy dobrym sprzęcie

BLE 5.x może osiągać kilkaset metrów w idealnych testach z użyciem Coded PHY, ale kosztem niższej przepustowości.

Rzeczywisty zasięg zależy bardziej od implementacji niż od samego wyboru BLE vs klasyczny.

Co naprawdę wpływa na zasięg

Czynniki, które zmieniają zasięg bardziej niż wybór protokołu:

• Moc nadawania (dBm): wyższa moc → większy zasięg → większe zużycie baterii
• Czułość odbiornika: lepsze układy słyszą słabsze sygnały
• Projekt anteny i orientacja: antena na chipie vs PCB vs zewnętrzna antena
• Przeszkody i materiały: beton, cegła, metal, a nawet ludzie tłumią 2.4 GHz
• Zakłócenia: Wi‑Fi, mikrofalówka i inne urządzenia 2.4 GHz
• PHY i szybkość transmisji: niższe szybkości poprawiają czułość i zasięg

BLE zdobywa przewagę, oferując kilka PHY (1M, 2M, Coded), które pozwalają wymieniać przepustowość na zasięg.

Przepustowość: burst vs stream

BLE jest zoptymalizowany pod krótkie, efektywne porcje danych.

• BLE 4.x: praktyczna przepustowość ~100–300 kb/s
• BLE 5 (1M / 2M PHY): do ~700–900 kb/s w idealnych warunkach
• BLE Coded PHY: znacznie mniejsza przepustowość, ale większy zasięg

Klasyczny Bluetooth (BR/EDR) nadal wygrywa dla ciągłych, wysokoprzepustowych strumieni:

• Praktyczna przepustowość często 1–2 Mbps
• Dostosowany do kodeków audio i nieprzerwanego przepływu danych

Dlatego słuchawki, głośniki i wiele starszych łączy danych wciąż korzystają z klasycznego Bluetooth.

Opóźnienia: sterowanie vs audio

Połączenia BLE mogą używać bardzo krótkich interwałów połączeń (nawet 7.5 ms), co daje niskie opóźnienia sterowania, które wydają się natychmiastowe dla przycisków, czujników i urządzeń HID.

Jednak BLE jest mniej odpowiedni do ciągłego, niskoopóźnieniowego audio. Harmonogramowanie pakietów, retransmisje i brak klasycznych profili audio utrudniają osiągnięcie spójnego opóźnienia poniżej 100 ms, które zapewnia BR/EDR audio.

Reguła praktyczna:

• BLE: świetne do sterowania, telemetryki i ruchu zdarzeniowego
• Klasyczny Bluetooth: lepszy do ciągłych strumieni multimedialnych, gdzie liczy się przepustowość i stabilne opóźnienie

Profile, GATT i modele danych: BLE vs klasyczny

Co oznaczają „profile” w Bluetooth

Profile Bluetooth to standaryzowane wzorce użycia, które leżą ponad warstwami radiowymi i linkowymi. Profil definiuje:

• Role urządzeń (np. source vs sink)
• Jakie protokoły są używane
• Jak formatowane i wymieniane są dane

Klasyczny Bluetooth mocno opiera się na takich profilach. Przykłady: A2DP (audio), HFP (hands‑free), HID (klawiatury/myszy), SPP (port szeregowy).

Jeśli dwa urządzenia implementują ten sam profil klasyczny, zwykle współpracują bez dodatkowej logiki w aplikacji.

GATT w BLE: model oparty na atrybutach zamiast kanałów

BLE zachował koncepcję „profilów”, ale przesunął się do modelu opartego na atrybutach:

• ATT (Attribute Protocol): protokół niskiego poziomu udostępniający dane jako tabelę atrybutów, każdy z uchwytem, typem (UUID), wartością i uprawnieniami.
• GATT (Generic Attribute Profile): definiuje, jak klient odkrywa, czyta, zapisuje i subskrybuje te atrybuty.

Dane grupowane są w:

• Serwisy: logiczne grupy (np. Heart Rate, Battery)
• Charakterystyki: pojedyncze punkty danych (np. measurement tętna, poziom baterii)
• Deskryptory: metadane o charakterystykach (jednostki, opis human‑readable)

Profile BLE są teraz definiowane jako kombinacje serwisów, charakterystyk i zachowań na bazie GATT.

Standardowe vs niestandardowe serwisy BLE

Bluetooth SIG publikuje wiele standardowych usług GATT, takich jak:

• Heart Rate Service (HRS)
• Device Information Service (DIS)
• Battery Service (BAS)

Korzystanie ze standardów poprawia interoperacyjność: każda aplikacja rozumiejąca Heart Rate Service porozumie się z zgodnym czujnikiem bez hacków zależnych od producenta.

Gdy brak standardu, producenci definiują niestandardowe serwisy z 128‑bitowymi UUID. Nadal używają procedur GATT, ale mają własne formaty danych.

Klasyczne profile vs GATT: kluczowe różnice

Klasyczny Bluetooth:

• Profile są często związane z konkretnymi przypadkami użycia i protokołami (np. audio przez A2DP używające kodeków SBC/aptX, kanały danych przez RFCOMM/L2CAP).
• Dane wymieniane są przez strumienie lub kanały; interpretacja często pozostawiona aplikacji.
• Interoperacyjność zależy od tego, czy obie strony zaimplementowały dokładnie ten sam profil.

BLE:

• Wszystko widoczne dla aplikacji jest modelowane jako atrybuty (serwisy, charakterystyki, deskryptory).
• Profile opisują zestawy atrybutów i procedury, a nie długotrwałe strumienie.
• Interoperacyjność popychana jest przez wspólne usługi GATT i charakterystyki, a nie pojedynczy monolityczny profil.

Przykłady: jak realne urządzenia modelują dane w BLE

Czujnik tętna typowo udostępnia:

• Heart Rate Service z charakterystyką Heart Rate Measurement wspierającą powiadomienia.
• Device Information Service z nazwą modelu i wersją firmware.
• Często Battery Service z poziomem baterii.

Uniwersalny peryferyjny (np. węzeł czujnikowy) może udostępniać:

• Niestandardowy serwis Sensor Service z charakterystykami Temperature, Humidity, Config.
• Temperature i Humidity jako read/notify. Config jako read/write dla parametrów (np. częstotliwości próbkowania).

Implikaacje dla inżynierów aplikacji i firmware

Dla firmware BLE oznacza, że musisz zaprojektować bazę GATT:

• Zdecyduj, które punkty danych staną się charakterystykami.
• Używaj standardowych serwisów, gdy to możliwe, żeby uniknąć reinventacji.
• Ustaw właściwości (read, write, notify, indicate) i uprawnienia (szyfrowanie, uwierzytelnienie) ostrożnie.

Dla programistów aplikacji interakcja z BLE to mniej „gniazda/sockety”, a więcej:

• Odkrywanie serwisów i charakterystyk.
• Odczyty/zapisy małych kawałków danych.
• Subskrypcje powiadomień o zmianach.

Ten model oparty na atrybutach jest zwykle łatwiejszy do zrozumienia niż tworzenie własnego protokołu binarnego nad klasycznym SPP, ale wymaga:

• Znajomości UUID i formatów danych dla każdej charakterystyki.
• Obsługi asynchronicznych powiadomień i stanów połączenia.

W skrócie: klasyczny Bluetooth daje profile oparte na kanałach i strumieniach, a BLE daje ustandaryzowany model atrybutów (GATT), który kształtujesz w profile przez definiowanie serwisów i charakterystyk ze zrozumiałym znaczeniem.