Mikroskop altında BLE (ATTы GATTы…)
Bölüm 1, genel bakış
Bluetooth 4.0'ın ilk spesifikasyonunun yayınlanmasından bu yana oldukça uzun bir zaman geçti. Ve BLE konusu çok ilginç olmasına rağmen karmaşıklığı nedeniyle birçok geliştiriciyi hala oyalıyor. Daha önceki yazılarımda ağırlıklı olarak en alt seviye olan Bağlantı Katmanı ve Fiziksel Katman'a bakmıştım. Bu, Nitelik Protokolü (ATT) ve Genel Nitelik Profili (GATT) gibi karmaşık ve kafa karıştırıcı kavramlara başvurmak zorunda kalmamızı sağladı. Ancak gidecek bir yer yok, bunları anlamadan uyumlu cihazlar geliştirmek mümkün değil. Bugün bu bilgiyi sizlerle paylaşmak istiyorum. Makalemde güveneceğim Nordic web sitesinden yeni başlayanlar için. Öyleyse başlayalım.
Neden her şey bu kadar zor?
Bana göre cihazları akıllı telefonlar üzerinden yönetmenin çok umut verici ve uzun vadeli bir konu olduğu hemen anlaşıldı. Bu nedenle derhal ve maksimum düzeyde yapılandırmaya karar verdiler. Böylece çeşitli gadget üreticileri kendi protokollerini geliştirmezler ve bu daha sonra uyumsuz olur. Bu nedenle zorluk. Zaten ilk aşamada mümkün olan her şeyi BLE protokolüne sıkıştırmaya çalıştılar. Ve daha sonra faydalı olup olmayacağı önemli değil. Ayrıca, cihaz listesinin geleceğe yönelik genişletilmesi olanağını da sağladılar.
BLE protokol diyagramının çizildiği resme bir göz atalım. Birkaç katmandan oluşur. En alttaki fiziksel katman (PHY), cihazın radyo kanalından sorumludur. Bağlantı Katmanı (LL), iletilen mesajdaki tüm bayt dizisini içerir. Önceki makalelerimizde tam olarak bunu inceledik. Ana Bilgisayar Denetleyici Arayüzü (HCI), Denetleyici ve Ana Bilgisayarın farklı yongalarda uygulanması durumunda BLE katmanları veya yongaları arasında bir değişim protokolüdür. Mantıksal Bağlantı Kontrolü ve Adaptasyon Protokolü (L2CAP), paket oluşumu, çerçeveleme, hata kontrolü ve paket birleştirmeden sorumludur. Güvenlik Yöneticisi Protokolü (SMP), paketlerin şifrelenmesinden sorumludur. Genel Erişim Profili (GAP), "Kimin kim olduğunu" belirlemek için cihazlar arasındaki ilk veri alışverişinden sorumludur. Aynı zamanda tarama ve reklamcılığı da içerir. Bu makalede protokolün geri kalan iki kısmına, GATT ve ATT'ye odaklanacağım. GATT, ATT'nin bir üst yapısıdır, dolayısıyla birbiriyle yakından ilişkilidir.
Hikayeyi basitleştirmek için bir benzetme yapmak istiyorum. Bir yerde duydum ve desteklemek isterim. BLE cihazını birkaç raflı bir kitaplık olarak düşünün. Her raf ayrı bir temadır. Örneğin bilim kurgu, matematik ve ansiklopedilerin bulunduğu raflarımız var. Her rafta belirli bir konuya sahip kitaplar vardır. Hatta bazı kitapların üzerinde notlar bulunan kağıt yer imleri bile vardır. Ayrıca tüm kitaplardan oluşan küçük bir kağıt kataloğumuz var. Hatırlarsanız okul kütüphaneleri kağıt kartların bulunduğu dar bir kutudur. Bu benzetmeyle dolap cihazımızın profilidir. Raflar hizmetlerdir, kitaplar özelliklerdir ve katalog da bir özellik tablosudur. Kitaplardaki yer imleri tanımlayıcılardır ve bundan daha sonra daha detaylı olarak bahsedeceğim.
Cihaz geliştiren herkes birçok projenin benzer kod parçalarına sahip olduğunu bilir. Gerçek şu ki, birçok cihaz benzer işlevselliğe sahiptir. Örneğin, cihazlar pillerle çalışıyorsa, şarj etme ve seviyelerini izleme sorunu aynı olacaktır. Aynı şey sensörler için de geçerli. Aslında programlamaya nesne yönelimli bir yaklaşım "Özellikleri ve davranışları bağımsız bir bütün halinde birleştiren ve daha sonra yeniden kullanılabilen nesneler yaratma yeteneği sağlar". Bana göre BLE de benzer bir yaklaşım denedi. Profiller Bluetooth Özel İlgi Grubu (SIG) tarafından geliştirilmiştir. Farklı üreticilerin aynı profile sahip cihazlarının birbirleriyle zorluk yaşamadan çalışması gerekir. Profiller ise tanımlayıcılarla desteklenen hizmetlerden ve karakteristik hizmetlerden oluşur. Genel olarak şöyle görünebilir:
Örneğin, bir kalp atış hızı monitörünün (spor bileziği) profil diyagramını düşünün. İki hizmetten ve çeşitli özelliklerden oluşur. Buradan profil hiyerarşisi hemen netleşiyor. Kontrol noktası özelliği toplam kalori harcamasını sıfıra sıfırlar.
1. Kalp atış hızı hizmeti üç özelliği içerir (0x180D):
a) Zorunlu kalp atış hızı karakteristiği (0x2A37)
b) İsteğe bağlı gövde sensörü konum karakteristiği (0x2A38)
c) Kalp atış hızı kontrol noktasının koşullu özellikleri (0x2A39)
2. Akü bakım servisi (0x180F):
a) Zorunlu akü şarj seviyesi karakteristiği (0x2A19)
UUID
Profil öğelerine (hizmetler, özellikler ve tanımlayıcılar) benzersiz bir şekilde erişebilmemiz için hepsini bir şekilde numaralandırmamız gerekiyor. Bu amaçla Evrensel Benzersiz Kimlik (UUID) veya Evrensel Benzersiz Tanımlayıcı gibi bir kavram tanıtılmaktadır. UUID her satırın parantezinde gösterilir. Ve burada bir tuhaflık var. UUID için 16 ve 128 bit uzunluğunda kod kullanmaya karar verdik. Neden soruyorsun? BLE protokolünde her şey enerji tasarrufu ile ilgilidir. Bu nedenle 16 bitlik boyut oldukça makuldür. Yakın gelecekte 65 binden fazlasının yaratılması pek mümkün görünmüyor. benzersiz hizmetler ve özellikler. Şu anda sayılabilecek her şey zaten sayılmış olabilir (bunun nereden geldiğini unutmayın - “o da sizi saydı” :-)) Numaralandırılmış öğeler , , и linklere bakabilirsiniz.
Ancak internetteki 4 baytlık IP adresleriyle ilgili hikayeyi herkesin hatırladığını düşünüyorum. İlk başta bunun yeterli olduğunu düşündük ama şu anda hala 6 byte'lık adrese geçemiyoruz. Bu hatayı tekrarlamamak ve DIY'cilerin oyunbaz ellerine serbestlik kazandırmak için SIG, hemen 128 bit UUID'leri sunmaya karar verdi. Bu bana şahsen radyo kanalından her türden Kulibin'e verilen lisanssız 433 MHz bandını hatırlatıyor. Bizim durumumuzda, hizmetlerin ve özelliklerin 128 bitlik bir tanımlayıcısı geliştirildi. Bu, hizmetlerimiz ve cihazlarımız için neredeyse her 128 bit değeri kullanabileceğimiz anlamına gelir. Yine de aynı UUID'yi bulma olasılığı sıfıra yakındır.
Aslında, 16 bitlik kısa UUID'lerin uzantısı 128 bitlik bir değere sahiptir. Spesifikasyonda bu uzantıya Bluetooth Base UUID adı veriliyor ve 00000000-0000-1000-8000-00805F9B34FB değerine sahip. Örneğin, 16 bitlik UUID özelliği 0x1234 değerine sahipse, eşdeğer 128 bitlik UUID, 00001234-0000-1000-8000-00805F9B34FB değerine sahip olacaktır. Ve buna karşılık gelen formül bile verilmiştir:
128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID
Bu sihirli sayının nereden geldiğini bilmiyorum. Okuyanlardan bilen varsa yorumlara yazsın (Bunu Sinopteek rumuzlu bir kullanıcı zaten yapmış. Yorumlara bakınız). 128 bit UUID'leri bulmaya gelince, prensip olarak özel bir kullanabilirsiniz. bunu senin için kim yapacak?
ATTy GATTy...
Aslında eğlence o zaman başlıyor. ATT'nin istemci-sunucu ilişkisine dayalı olduğunu hatırlatmama izin verin. Şimdi sunucu cihazına bakıyoruz. Sensör değerleri, ışık anahtarı durumu, konum verileri vb. bilgileri içerir. Artık "geçit törenimize katılanların" tümü numaralandırıldığına göre, onları bir şekilde cihazın hafızasına yerleştirmemiz gerekiyor. Bunu yapmak için bunları nitelik tablosu adı verilen bir tabloya yerleştiririz. Bunu iyi hatırla. Bu BLE'nin kalbidir. Daha fazla ele alacağımız şey budur. Şimdi her satıra bir nitelik adını vereceğiz. Bu tablo yığının derinliklerinde bulunur ve kural olarak ona doğrudan erişimimiz yoktur. Onu başlatıyoruz ve ona erişiyoruz, ancak içeride olup bitenler yedi mührün arkasında bizden gizli.
Resme spesifikasyondan bakalım ama ondan önce terim yani tanımlayıcılarda sık sık yaşanan kafa karışıklığına hemen dikkat çekmek istiyorum. Tanımlayıcının rolü, özelliğin tanımını tamamlamaktır. Yeteneklerini genişletmek gerektiğinde tanımlayıcılar kullanılır. Bunlar aynı zamanda niteliklerdir ve tıpkı hizmetler ve özellikler gibi, nitelik tablosunda yer alırlar. Bunları yazımızın ikinci bölümünde detaylı olarak inceleyeceğiz. Ancak bazen tanımlayıcılar öznitelik tablosundaki satır numarasına atıfta bulunur. Bu akılda tutulmalıdır. Karışıklığı önlemek için bu amaçlar doğrultusunda "öznitelik işaretçisi" terimini kullanacağız.
Dolayısıyla bir nitelik, kendisiyle ilişkilendirilmiş aşağıdaki özelliklere sahip ayrı bir değerdir:
1. Öznitelik Tutamacı, özniteliğe karşılık gelen tablo dizini
2. Öznitelik Türü, türünü tanımlayan bir UUID'dir
3. Özellik Değeri, özellik işaretçisi tarafından indekslenen verilerdir
4. Öznitelik İzinleri, özniteliğin, yani izinlerin, öznitelik protokolü kullanılarak okunamayan veya yazılamayan kısmıdır.
Bütün bunlar nasıl anlaşılır? Nitelik işaretçisi göreceli olarak tablomuzdaki numarasıdır.
Bir istemcinin okuma veya yazma isteklerinde bir özniteliğe başvurmasına olanak tanır. Satırlarımızı (niteliklerimizi) 0x0001'den 0xFFFF'ye kadar numaralandırabiliriz. Kitaplık ile olan ilişkimizde bu, kağıt katalogdaki kart numarasıdır. Benzer şekilde kütüphane kataloğunda olduğu gibi kartlar da büyükten küçüğe sıralanmıştır. Sonraki her satırın sayısı bir öncekinden büyük olmalıdır. Tıpkı kütüphanede olduğu gibi bazen bazı kartlar kayboluyor, bizde de satır numaralarında boşluklar olabiliyor. Buna izin veriliyor. Önemli olan, aşamalı olarak ilerlemeleridir.
Özellik türü, özelliğin neyi temsil ettiğini belirler. C diline benzetmek gerekirse,
boolean, sayısal değişkenler ve dizelerin olduğu yerde, işte burada. Özellik türüne göre tanıyoruz
neyle uğraşıyoruz ve bu özelliğimizle çalışmaya nasıl devam edebiliriz. Aşağıda bazı spesifik özellik türlerine bakacağız. Örneğin, “hizmet beyanı” (0x2800), “karakteristik beyanı” (0x2803), “tanımlayıcı beyanı” (0x2902).
Bir niteliğin değeri onun gerçek anlamıdır, totolojiyi bağışlayın. Nitelik türü bir dize ise, nitelik değeri örneğin “Merhaba Dünya !!!” sloganı olabilir. Öznitelik türü bir "hizmet beyanı" ise değeri hizmetin kendisidir. Ve bazen bu, diğer niteliklerin ve onların özelliklerinin nerede bulunabileceğine ilişkin bilgilerdir.
Öznitelik izinleri, sunucunun okuma veya yazma erişimine izin verilip verilmediğini anlamasına olanak tanır.
Bu izinlerin yalnızca öznitelik değeri için geçerli olduğunu; işaretçi, tür veya izin alanının kendisi için geçerli olmadığını unutmayın. Onlar. nitelik kaydına izin veriliyorsa, örneğin “Merhaba Dünya !!!” satırını değiştirebiliriz. “Günaydın” satırına. Ancak yeni bir satır yazmayı yasaklayamayız veya nitelik türünü değiştirip satırı “hizmet beyanı” olarak tanımlayamayız. Bir istemci bir sunucuyla iletişim kurduğunda, istemci onun niteliklerini ister. Bu, istemcinin sunucunun neler sağlayabileceğini bilmesini sağlar. Değerleri okuyup yazmanıza gerek olmamasına rağmen.
Neye benziyor
GATT'ın konsepti, bir nitelik tablosundaki nitelikleri çok spesifik ve mantıksal bir sırayla gruplandırmaktır. Aşağıdaki kalp atış hızı profiline daha yakından bakalım. Bu tablonun en soldaki sütunu isteğe bağlıdır. Bize basitçe bu satırın (özniteliğin) ne olduğunu açıklar. Diğer tüm sütunlar bize zaten tanıdık geliyor.
Her grubun en üstünde her zaman bir hizmet bildirimi özelliği bulunur. Türü her zaman 0x2800'dür ve işaretçi, tabloda halihazırda kaç özelliğin mevcut olduğuna bağlıdır. İzinleri, herhangi bir kimlik doğrulama veya yetkilendirme olmaksızın her zaman salt okunurdur. Bu kavramlara biraz sonra değineceğiz. Değer, hizmetin ne olduğunu tanımlayan başka bir UUID'dir. Tabloda değer, Bluetooth SIG tarafından kalp atış hızı hizmeti olarak tanımlanan 0x180D'dir.
Hizmetin duyurulmasından sonra karakteristik duyurusu gelir. Biçim olarak hizmet beyanına benzer. UUID'si her zaman 0x2803'tür ve izinleri, herhangi bir kimlik doğrulama veya yetkilendirme olmaksızın her zaman salt okunurdur. Bazı verileri içeren Öznitelik Değeri alanına bakalım. Her zaman bir işaretçi, bir UUID ve bir dizi özellik içerir. Bu üç öğe, karakteristik değerin sonraki bildirimini tanımlar. İşaretçi doğal olarak özellik tablosundaki karakteristik değer bildiriminin konumunu belirtir. UUID, ne tür bilgi veya değer bekleyebileceğimizi açıklar. Örneğin sıcaklık değeri, ışık anahtarının durumu veya başka bir keyfi değer. Ve son olarak karakteristik değerle nasıl etkileşime girilebileceğini tanımlayan özellikler.
Burada bizi başka bir tuzak bekliyor. Öznitelik izinleri ve karakteristik özelliklerle ilişkilidir. Şartnamedeki bit alanı özelliklerinin resmine bakalım.
Gördüğünüz gibi burada okuma ve yazma yeteneği sağlayan alanlar da var. Nitelik ve özellik için neden okuma/yazma izinlerine sahip olduğumuzu merak ediyor olabilirsiniz.
karakteristik değer için okuma/yazma? Hep aynı olmaları gerekmez mi? Gerçek şu ki, karakteristik değere ilişkin özellikler aslında yalnızca GATT'da ve uygulama katmanlarında kullanılan istemciye yönelik önerilerdir. Bunlar sadece müşterinin karakteristik bildirim özelliğinden ne bekleyebileceğine dair ipuçlarıdır. Buna daha detaylı bakalım. Bir özelliğin ne tür izinleri vardır?
1. Erişim izinleri:
- okuma
- kayıt
- oku ve yaz
2. Kimlik doğrulama izni:
- kimlik doğrulama gerekli
- kimlik doğrulamaya gerek yok
3. Yetki izni:
- izin gerekmekte
- yetkilendirmeye gerek yok
Öznitelik çözümlemesi ile karakteristik özellikler arasındaki temel fark, birincisinin sunuculara, ikincisinin ise istemcilere uygulanmasıdır. Sunucunun karakteristik değeri okumasına izin verilebilir ancak kimlik doğrulama veya yetkilendirme gerekebilir. Bu nedenle müşteri karakteristiğin özelliklerini talep ettiğinde okumaya izin verildiğini alırız. Ancak okumaya çalıştığımızda hata alıyoruz. Bu nedenle izinlerin mülklere göre önceliğinden rahatlıkla bahsedebiliriz. İstemci tarafında, bir özelliğin hangi izinlere sahip olduğu hakkında bilgi sahibi olamayız.
Tanımlayıcı
Masamıza dönelim. Bir özelliğin değeri bildirildikten sonra aşağıdaki öznitelik bildirimleri mümkündür:
1. Yeni özellik beyanı (bir hizmetin birçok özelliği olabilir)
2. Yeni hizmet beyanı (tabloda çok sayıda olabilir)
3. Bir tanıtıcının bildirilmesi
Kalp atış hızı ölçüm karakteristiği durumunda, tablomuzda karakteristik değerin beyanına tanımlayıcının beyanı eşlik etmektedir. Tanımlayıcı, bir karakteristik hakkında ek bilgi içeren bir niteliktir. Birkaç tür tanımlayıcı vardır. Bu makalenin ikinci bölümünde bunlardan detaylı olarak bahsedeceğiz. Şimdilik sadece İstemci Karakteristik Konfigürasyon Tanımlayıcısına (CCCD) değineceğiz. 0x2902'ye eşit bir UUID'ye sahiptir. Bu tanımlayıcıyı kullanarak istemci, sunucuda göstergeyi veya bildirimi etkinleştirme olanağına sahiptir. Aralarındaki fark küçük ama yine de var. Bildirim, müşteriden alındığının onaylanmasını gerektirmez. Gösterge bunu gerektirir, her ne kadar GATT düzeyinde gerçekleşse de, uygulama düzeyine ulaşamasa da. Neden peki diye sordun mu? Ne yazık ki bunu bilmiyorum. İskandinav uzmanlarının bildirimleri kullanmanızı önerdiğini söylememe izin verin. Ayrıca, paketin bütünlüğünün kontrol edilmesi (CRC kullanılarak) her iki durumda da gerçekleşir.
Sonuç
Yazının sonunda şunu söylemek isterim. Son tablo biraz kafa karıştırıcı. Ancak verildiği için bunu seçtim. , buna güveniyorum. Yazımın ikinci bölümünde BlueTooth 4.0 spesifikasyonunu daha derinlemesine incelemeyi planlıyorum. Orada daha doğru diyagramlar ve çizimler bizi bekliyor. Üçüncü bölümde, Wireshark programını kullanarak gadget'lardan birinden elde edilen günlüğü ayrıştırmak ve üzerinde çalıştığımız tüm teoriyi "canlı" görmek istiyorum.
Şirketler Grubu Çalışanı
Peçerskikh Vladimir
Kaynak: habr.com