BLE di bawah mikroskop (ATTы GATTы…)
Bagian 1, ikhtisar
Sudah cukup lama berlalu sejak spesifikasi pertama Bluetooth 4.0 dirilis. Dan meskipun topik BLE sangat menarik, topik ini masih membuat banyak pengembang enggan karena kerumitannya. Dalam artikel saya sebelumnya, saya terutama melihat level paling bawah, Lapisan Tautan dan Lapisan Fisik. Hal ini memungkinkan kami menghindari penggunaan konsep yang rumit dan membingungkan seperti Attribute Protocol (ATT) dan General Attribute Profile (GATT). Namun, tidak ada tujuan lain, tanpa memahaminya, tidak mungkin mengembangkan perangkat yang kompatibel. Hari ini saya ingin berbagi pengetahuan ini dengan Anda. Dalam artikel saya, saya akan mengandalkan untuk pemula dari situs web Nordic. Jadi mari kita mulai.
Mengapa semuanya begitu sulit?
Menurut pendapat saya, jelas sekali bahwa mengelola perangkat melalui ponsel pintar adalah topik yang sangat menjanjikan dan bertahan lama. Oleh karena itu, mereka memutuskan untuk segera menyusunnya dan semaksimal mungkin. Sehingga produsen berbagai gadget tidak membuat protokolnya sendiri yang kemudian menjadi tidak kompatibel. Oleh karena itu kesulitannya. Sudah pada tahap pertama, mereka mencoba memasukkan segala kemungkinan ke dalam protokol BLE. Dan tidak peduli apakah itu berguna nantinya atau tidak. Selain itu, mereka memberikan kemungkinan untuk memperluas daftar perangkat untuk masa depan.
Mari kita lihat gambar diagram protokol BLE. Terdiri dari beberapa lapisan. Lapisan fisik terendah (PHY) bertanggung jawab atas saluran radio perangkat. Lapisan Tautan (LL) berisi seluruh urutan byte dalam pesan yang dikirimkan. Dalam artikel sebelumnya kami mempelajari hal ini dengan tepat. Host Controller Interface (HCI) merupakan protokol pertukaran antar lapisan atau chip BLE jika Controller dan Host diimplementasikan pada chip yang berbeda. Logical Link Control and Adaptation Protocol (L2CAP) bertanggung jawab atas pembentukan paket, pembingkaian, kontrol kesalahan, dan perakitan paket. Security Manager Protocol (SMP) bertanggung jawab untuk mengenkripsi paket. Profil Akses Umum (GAP) bertanggung jawab atas pertukaran data awal antar perangkat untuk menentukan “Siapa adalah siapa”. Ini juga mencakup pemindaian dan periklanan. Pada artikel ini saya akan fokus pada dua bagian protokol yang tersisa - GATT dan ATT. GATT merupakan suprastruktur dari ATT, sehingga keduanya saling terkait erat.
Untuk menyederhanakan ceritanya, saya ingin beralih ke sebuah analogi. Saya mendengarnya di suatu tempat dan ingin mendukungnya. Bayangkan perangkat BLE sebagai rak buku dengan beberapa rak. Setiap rak adalah tema terpisah. Misalnya, kami memiliki rak berisi fiksi ilmiah, matematika, dan ensiklopedia. Di setiap rak terdapat buku-buku dengan topik tertentu. Dan beberapa buku bahkan memiliki penanda kertas dengan catatan. Selain itu, kami memiliki katalog kertas kecil yang berisi semua buku. Jika Anda ingat, perpustakaan sekolah adalah sebuah kotak sempit berisi kartu kertas. Dengan analogi ini, kabinet adalah profil perangkat kita. Rak adalah layanan, buku adalah karakteristik, dan katalog adalah tabel atribut. Bookmark di buku adalah deskriptor, yang juga akan saya bahas lebih detail nanti.
Siapa pun yang telah mengembangkan perangkat tahu bahwa banyak proyek memiliki kode serupa. Faktanya adalah banyak perangkat memiliki fungsi serupa. Misalnya, jika perangkat ditenagai oleh baterai, maka masalah pengisian daya dan pemantauan levelnya akan sama. Hal yang sama berlaku untuk sensor. Sebenarnya, pendekatan pemrograman berorientasi objek “memberikan kemampuan untuk membuat objek yang menggabungkan properti dan perilaku menjadi satu kesatuan mandiri yang kemudian dapat digunakan kembali”. Menurut pendapat saya, BLE mencoba pendekatan serupa. Profil dikembangkan oleh Bluetooth Special Interest Group (SIG). Perangkat dari pabrikan berbeda yang memiliki profil sama akan bekerja satu sama lain tanpa kesulitan. Profil, pada gilirannya, terdiri dari layanan, dan layanan karakteristik, dilengkapi dengan deskriptor. Secara umum mungkin terlihat seperti ini:
Misalnya, perhatikan diagram profil monitor detak jantung (gelang kebugaran). Ini terdiri dari dua layanan dan beberapa karakteristik. Dari situ hierarki profil segera menjadi jelas. Karakteristik pos pemeriksaan mengatur ulang jumlah total pengeluaran kalori menjadi nol.
1. Layanan detak jantung mencakup tiga karakteristik (0x180D):
a) Karakteristik detak jantung wajib (0x2A37)
b) Karakteristik posisi sensor bodi opsional (0x2A38)
c) Karakteristik kondisional dari titik kontrol detak jantung (0x2A39)
2. Layanan pemeliharaan baterai (0x180F):
a) Karakteristik tingkat pengisian daya baterai wajib (0x2A19)
UUID
Agar kita dapat mengakses elemen profil (layanan, karakteristik, dan deskriptor) secara unik, kita perlu memberi nomor pada semuanya. Untuk tujuan ini, konsep seperti Universally Unique ID (UUID) atau Universally Unique Identifier diperkenalkan. UUID ditunjukkan dalam tanda kurung di setiap baris. Dan ada satu kekhasan di sini. Untuk UUID, kami memutuskan untuk menggunakan kode yang panjangnya 16 dan 128 bit. Mengapa kamu bertanya? Dalam protokol BLE, semuanya berkaitan dengan konservasi energi. Oleh karena itu, dimensi 16 bit cukup masuk akal. Kecil kemungkinannya akan ada lebih dari 65 ribu yang tercipta dalam waktu dekat. layanan dan karakteristik yang unik. Saat ini, semua yang mereka bisa sudah dihitung (ingat dari mana asalnya - “dia menghitungmu juga” :-)) Elemen bernomor , , и Anda dapat melihat tautannya.
Namun, saya rasa semua orang ingat cerita dengan 4 byte alamat IP di Internet. Awalnya kami pikir itu sudah cukup, tapi sekarang kami masih tidak bisa beralih ke alamat 6-byte. Agar tidak mengulangi kesalahan ini dan memberikan kebebasan kepada para DIYers, SIG segera memutuskan untuk memperkenalkan UUID 128-bit. Ini secara pribadi mengingatkan saya pada pita 433 MHz tanpa izin, yang diberikan kepada semua jenis Kulibin dari saluran radio. Dalam kasus kami, pengidentifikasi layanan dan karakteristik 128-bit telah digunakan. Artinya, kami, untuk layanan dan perangkat kami, dapat menggunakan hampir semua nilai 128-bit. Meski begitu, kemungkinan munculnya UUID yang sama cenderung nol.
Faktanya, UUID 16-bit pendek memiliki ekstensi hingga nilai 128-bit. Secara spesifikasi, ekstensi ini disebut Bluetooth Base UUID dan memiliki nilai 00000000-0000-1000-8000-00805F9B34FB. Jika, misalnya, UUID atribut 16-bit memiliki nilai 0x1234, maka UUID 128-bit yang setara akan memiliki nilai 00001234-0000-1000-8000-00805F9B34FB. Dan bahkan rumus yang sesuai diberikan:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Saya tidak tahu dari mana angka ajaib ini berasal. Jika ada pembaca yang mengetahuinya, biarkan mereka menulis di komentar (Pengguna dengan nama panggilan Sinopteek telah melakukan ini. Lihat komentar). Sedangkan untuk membuat UUID 128-bit, pada prinsipnya bisa menggunakan yang khusus siapa yang akan melakukannya untukmu.
ATty GATTy...
Sebenarnya, kesenangan pun dimulai. Izinkan saya mengingatkan Anda bahwa ATT didasarkan pada hubungan klien-server. Sekarang kita sedang melihat perangkat server. Ini berisi informasi seperti nilai sensor, status sakelar lampu, data lokasi, dll. Sekarang setelah semua “peserta parade kita” diberi nomor, kita perlu menempatkan mereka di memori perangkat. Untuk melakukan ini, kami menempatkannya dalam sebuah tabel yang disebut tabel atribut. Ingatlah ini baik-baik. Inilah inti dari BLE. Inilah yang akan kami pertimbangkan lebih lanjut. Sekarang kita akan menyebut setiap baris sebagai atribut. Tabel ini terletak jauh di dalam tumpukan dan, sebagai aturan, kami tidak memiliki akses langsung ke sana. Kami menginisialisasinya dan mengaksesnya, tetapi apa yang terjadi di dalamnya tersembunyi dari kami di balik tujuh segel.
Mari kita lihat gambarnya dari spesifikasinya, namun sebelum itu saya ingin segera menarik perhatian pada seringnya terjadi kebingungan dalam istilah yaitu pada deskriptornya. Peran deskriptor adalah melengkapi deskripsi karakteristik. Ketika diperlukan untuk memperluas kemampuannya, maka deskriptor digunakan. Mereka juga merupakan atribut, dan sama seperti layanan dan karakteristik, mereka terletak di tabel atribut. Kami akan memeriksanya secara rinci di bagian kedua artikel. Namun, terkadang deskriptor merujuk pada nomor baris dalam tabel atribut. Ini harus diingat. Untuk menghindari kebingungan, kami akan menggunakan istilah “penunjuk atribut” untuk tujuan ini.
Jadi atribut adalah nilai diskrit yang memiliki sifat-sifat berikut yang terkait dengannya:
1. Attribute Handle adalah indeks tabel yang sesuai dengan atribut
2. Tipe Atribut adalah UUID yang menjelaskan tipenya
3. Nilai Atribut adalah data yang diindeks oleh penunjuk atribut
4. Izin Atribut adalah bagian dari atribut, izin, yang tidak dapat dibaca atau ditulis menggunakan protokol atribut
Bagaimana memahami semua ini? Penunjuk atribut, secara relatif, adalah nomornya di tabel kita.
Hal ini memungkinkan klien untuk mereferensikan atribut dalam permintaan baca atau tulis. Kita dapat memberi nomor pada baris (atribut) kita dari 0x0001 hingga 0xFFFF. Dalam hubungan kami dengan rak buku, ini adalah nomor kartu dalam katalog kertas. Sama halnya dengan katalog perpustakaan, kartu-kartu disusun menurut urutan nomornya. Jumlah setiap baris berikutnya harus lebih besar dari baris sebelumnya. Sama seperti di perpustakaan, terkadang beberapa kartu hilang, jadi di perpustakaan kami, mungkin ada celah dalam penomoran baris. Ini diperbolehkan. Hal utama adalah mereka bergerak secara progresif.
Tipe atribut menentukan apa yang diwakili oleh atribut tersebut. Dengan analogi dengan bahasa C,
dimana terdapat boolean, variabel numerik dan string, jadi disini. Berdasarkan jenis atribut yang kami kenali
apa yang kami hadapi dan bagaimana kami dapat terus bekerja dengan atribut ini. Di bawah ini kita akan melihat beberapa jenis atribut tertentu. Misalnya, “deklarasi layanan” (0x2800), “deklarasi karakteristik” (0x2803), “deklarasi deskriptor” (0x2902).
Nilai suatu atribut adalah arti sebenarnya, maafkan tautologinya. Jika tipe atributnya adalah string, maka nilai atributnya bisa berupa slogan “Hello World!!!”. Jika tipe atributnya adalah “deklarasi layanan”, maka nilainya adalah layanan itu sendiri. Dan terkadang ini adalah informasi tentang di mana menemukan atribut lain dan propertinya.
Izin atribut memungkinkan server memahami apakah akses baca atau tulis diperbolehkan.
Perhatikan bahwa izin ini hanya berlaku pada nilai atribut, dan bukan pada bidang penunjuk, tipe, atau izin itu sendiri. Itu. jika perekaman atribut diperbolehkan, maka kita dapat mengubah, misalnya baris “Hello World!!!” ke baris "Selamat pagi". Namun kami tidak dapat melarang penulisan baris baru atau mengubah jenis atribut dan menetapkan baris tersebut sebagai “deklarasi layanan”. Ketika klien menghubungi server, klien meminta atributnya. Hal ini memungkinkan klien mengetahui apa yang dapat disediakan oleh server. Meskipun tidak perlu membaca dan menulis nilainya.
Seperti apa bentuknya
Konsep GATT adalah mengelompokkan atribut-atribut dalam suatu tabel atribut bersama-sama dalam urutan yang sangat spesifik dan logis. Mari kita lihat lebih dekat profil detak jantung di bawah ini. Kolom paling kiri dari tabel ini bersifat opsional. Ini hanya menjelaskan kepada kita apa baris (atribut) ini. Semua kolom lainnya sudah tidak asing lagi bagi kami.
Di bagian atas setiap grup kami selalu memiliki atribut deklarasi layanan. Tipenya selalu 0x2800, dan penunjuknya bergantung pada berapa banyak atribut yang sudah ada di tabel. Izinnya selalu hanya-baca, tanpa otentikasi atau otorisasi apa pun. Kita akan membicarakan konsep ini nanti. Nilainya adalah UUID lain yang mengidentifikasi layanan tersebut. Pada Tabel, nilainya adalah 0x180D, yang ditentukan oleh Bluetooth SIG sebagai layanan detak jantung.
Setelah pengumuman layanan, muncul pengumuman karakteristiknya. Bentuknya mirip dengan deklarasi layanan. UUID-nya selalu 0x2803, dan izinnya selalu hanya-baca tanpa autentikasi atau otorisasi apa pun. Mari kita lihat bidang Nilai Atribut, yang berisi beberapa data. Itu selalu berisi pointer, UUID, dan sekumpulan properti. Ketiga elemen ini menggambarkan deklarasi nilai karakteristik selanjutnya. Pointer secara alami menunjukkan lokasi deklarasi nilai karakteristik dalam tabel atribut. UUID menjelaskan jenis informasi atau nilai apa yang dapat kita harapkan. Misalnya, nilai suhu, status saklar lampu, atau nilai sembarang lainnya. Dan terakhir properti, yang menjelaskan bagaimana nilai karakteristik dapat berinteraksi.
Jebakan lain menanti kita di sini. Hal ini terkait dengan izin atribut dan properti karakteristik. Mari kita lihat gambar properti bit field dari spesifikasinya.
Seperti yang Anda lihat, ada juga bidang di sini yang menyediakan kemampuan membaca dan menulis. Anda mungkin bertanya-tanya mengapa kami memiliki izin baca/tulis untuk atribut dan properti
baca/tulis untuk nilai karakteristik? Bukankah seharusnya mereka selalu sama? Faktanya adalah properti untuk nilai karakteristik sebenarnya hanya rekomendasi untuk klien yang digunakan di GATT dan lapisan aplikasi. Ini hanyalah petunjuk tentang apa yang klien harapkan dari atribut deklarasi karakteristik. Mari kita lihat ini lebih terinci. Jenis izin apa yang dimiliki suatu atribut?
1. Izin akses:
- membaca
- catatan
- Baca dan tulis
2. Izin otentikasi:
- otentikasi diperlukan
- tidak diperlukan otentikasi
3. Izin otorisasi:
— otorisasi diperlukan
- tidak diperlukan otorisasi
Perbedaan utama antara resolusi atribut dan properti karakteristik adalah bahwa properti karakteristik berlaku untuk server, dan properti karakteristik berlaku untuk klien. Server mungkin diizinkan untuk membaca nilai karakteristik, tetapi mungkin memerlukan otentikasi atau otorisasi. Oleh karena itu, ketika klien meminta properti dari karakteristik tersebut, kami akan menerima bahwa pembacaan diperbolehkan. Namun ketika kami mencoba membaca, kami mendapatkan kesalahan. Oleh karena itu, kita dapat dengan aman membicarakan prioritas izin di atas properti. Di sisi klien, kami tidak dapat memperoleh pengetahuan tentang izin apa yang dimiliki suatu atribut.
Deskripsi
Mari kita kembali ke meja kita. Setelah mendeklarasikan nilai suatu karakteristik, deklarasi atribut berikut dapat dilakukan:
1. Deklarasi karakteristik baru (suatu layanan dapat memiliki banyak karakteristik)
2. Deklarasi layanan baru (mungkin ada banyak di tabel)
3. Mendeklarasikan pegangan
Dalam hal karakteristik pengukuran detak jantung, dalam tabel kami, deklarasi nilai karakteristik disertai dengan deklarasi deskriptor. Deskriptor adalah atribut yang berisi informasi tambahan tentang suatu karakteristik. Ada beberapa jenis deskriptor. Kami akan membicarakannya secara rinci di bagian kedua artikel ini. Untuk saat ini, kami hanya akan membahas Deskriptor Konfigurasi Karakteristik Klien (CCCD). Ini memiliki UUID yang sama dengan 0x2902. Dengan menggunakan deskriptor ini, klien memiliki kemampuan untuk mengaktifkan indikasi atau pemberitahuan di server. Perbedaan di antara mereka kecil, tapi tetap ada. Pemberitahuan tidak memerlukan konfirmasi penerimaan dari klien. Indikasi memerlukan hal tersebut, meskipun terjadi pada level GATT, belum sampai pada level penerapan. Mengapa demikian, Anda bertanya? Sayangnya, saya tidak mengetahui hal ini. Izinkan saya mengatakan bahwa para ahli Nordik merekomendasikan penggunaan notifikasi. Selain itu, pemeriksaan integritas paket (menggunakan CRC) terjadi pada kedua kasus.
Kesimpulan
Di akhir artikel saya ingin mengatakan ini. Tabel terakhir agak membingungkan. Namun, saya memilihnya karena sudah diberikan , yang saya andalkan. Di bagian kedua artikel saya, saya bermaksud mempelajari lebih dalam tentang spesifikasi BlueTooth 4.0. Diagram dan gambar yang lebih tepat menunggu kita di sana. Pada bagian ketiga, saya ingin mengurai log yang diperoleh dengan menggunakan program Wireshark dari salah satu gadget dan melihat “langsung” seluruh teori yang sedang kita pelajari.
Karyawan Grup Perusahaan
Pecherskikh Vladimir
Sumber: www.habr.com