Bluetooth v4
- növeli az adatátvitel és -vétel sebességét;
- az internethez való csatlakozás képessége;
- Jobb magánélet és biztonság.
A sajtóközlemény fő tézise: 4.2 verzió - ideális a tárgyak internetéhez (IoT).
Ebben a cikkben szeretném elmondani, hogy miként hajtják végre ezeket a 3 pontot. Kinek érdekes szívesen.
Az alábbiakban ismertetettek mindegyike csak a BLE-re vonatkozik, vezetett ...
1. Növelje a felhasználói adatok fogadásának és továbbításának sebességét.
A BLE fő hátránya az alacsony adatátviteli sebesség volt. Bár melyik oldalról nézni, mert eredetileg BLE feltalálta, hogy megmentse az energiaforrást, amely a készüléket táplálja. És azért, hogy energiát takarítsunk meg, időnként kommunikálni és továbbadni egy kis adatot. Mindazonáltal az internet egésze tele van az alacsony sebességgel kapcsolatos zavarokkal és a felgyorsítás lehetőségével kapcsolatos kérdésekkel, valamint a továbbított adatok méretének növelésével.
A 4.2-es verzió megjelenésével a Bluetooth SIG bejelentette, hogy a továbbítási sebesség 2,5-szeresével, az átvitt csomag 10-szeresével nőtt. Hogyan sikerült ezt elérni?
Megmondom, hogy ezek a két számok egymáshoz kapcsolódnak, nevezetesen: a sebesség növekedése, mert a továbbított csomag mérete megnövekedett.
Nézzük az adatcsatorna PDU-ját (protokoll adategységét):
Minden PDU tartalmaz egy 16 bites fejlécet. Tehát ez a fejléc a 4.2 verzióban eltér a 4.1-es verzió fejlécétől.
Itt van a 4.1 verzió címe:
De a 4.2 verzió címe:
Megjegyzés: RFU (fenntartva a jövőbeli használatra) - a rövidítéssel jelölt mező későbbi felhasználásra van fenntartva, és tele van nullákkal.
Amint láthatjuk, a fejléc utolsó 8 bitje eltérő. A "Hosszúság" mező a PDU-ban (ha az utóbbiak be van kapcsolva) a hasznos terhelés hossza és a MIC mező (Message Integrity Check) összege.
Ha a 4.1-es verzióban a "Hossz" mező 5 bites, akkor a 4.2-es verzióban ez a mező 8 bites méretű.
Ezért könnyen kiszámítható, hogy a mező «hossz» verzióban 4.1 tartalmazhat-értéke 0-31, és 4,2 közötti tartományban 0 és 255 Ha az érték levonjuk a maximális hosszúságú mező MIC (4 oktett), akkor azt látjuk, hogy hasznos adatok lehetnek 27 és 251 oktettek a 4.1-es és a 4.2-es verzióhoz. Valójában az adatok maximális száma még kevésbé, mert A hasznos teher tartalmazza az L2CAP (4 oktett) és az ATT (3 oktett) szolgáltatásadatait is, de ezt nem vesszük figyelembe.
Így a továbbított felhasználói adatok mérete körülbelül 10-szeresére nőtt. Ami a sebesség, amely valamilyen okból nőtt 10-szer, míg csak 2,5-szer, akkor nem lehet beszélni arányosan növelni, mert minden nyugszik, még a szállítási garancia adatok, mert annak biztosítása érdekében, a szállítás 200 byte egy kicsit nehezebb mint 20.
2. Az internethez való csatlakozás képessége.
Talán a legérdekesebb újítás, amely miatt a Bluetooth SIG és bejelentette, hogy a 4.2-es verziója az internet a dolgok (IoT) jobb köszönhetően ezt a funkciót.
A 4.1-es verzióban a "LE Credit Based Flow Control Mode" mód az L2CAP-ban jelent meg. Ez az üzemmód lehetővé teszi az adatok áramlását úgy, hogy az úgynevezett. hitel alapú rendszer. A rendszer sajátossága, hogy nem használ jelcsomagokat a továbbított adatok számának megadására, hanem egy másik eszközről egy bizonyos mennyiségű adatot kér a továbbításért, ami felgyorsítja az átviteli folyamatot. Ebben az esetben a vételi oldal mindegyik alkalommal fogadja a keretet, csökkenti a keretszámlálót, és az utolsó keret elérésekor megszakíthatja a kapcsolatot.
Az L2CAP parancsok listáján 3 új kód jelent meg:
- LE Credit Based Connection kérelem - hitelkeret-összeköttetés kérése;
- LE Credit Based Connection válasz - válasz a hitelkerethez való kapcsolatra;
- LE Flow Control Credit - üzenet arról a lehetőségről, hogy további LE képkockákat kap.
A "LE Credit Based Connection" kérés csomagjában
Van egy "kezdeti kredit" mező, amely 2 oktett hosszú, és jelzi a LE képkockák számát, amelyeket a készülék küldhet az L2CAP szintjén.
A "LE Credit Based Connection válasz" válaszcsomagban
ugyanabban a mezőben meg kell adni a másik eszköz által küldhető LE-keretek számát, és a kapcsolatkérelem eredményét a "Eredmény" mezőben kell megadni. A 0x0000 érték jelzi a sikert, a fennmaradó értékek hibát jeleznek. Különösen a 0x0004 érték azt jelzi, hogy az erőforrások hiánya miatt csatlakozási hiba történt.
Így még a 4.1-es verzióban is lehetőség van nagy mennyiségű adat átvitelére az L2CAP szintjén.
És most, szinte egyidejűleg a 4.2 verzió kiadásával, megjelenik:
A fő követelmény profil L2CAP szint «LE alapján Credit Connection» megjelent 4.1-es verziója, ami viszont lehetővé teszi, hogy csomagokat küldeni MTU> = 1280 oktett (reméljük, hogy kitaláljuk hint érthető).
A profil meghatározza a következő szerepeket:
- útválasztó szerepe (router) - olyan eszközökhöz használható, amelyek IPv6 csomagokat irányíthatnak;
- csomópont-szerepkör (csomópont) - olyan eszközökön használható, amelyek csak IPv6 csomagokat fogadhatnak vagy küldhetnek; rendelkezzen szolgáltatáskeresési funkcióval és rendelkezik egy olyan IPSS szolgáltatással, amely lehetővé teszi az útválasztók számára az eszköz észlelését;
A router szerepkörrel rendelkező eszközöknek, amelyeknek kapcsolódniuk kell egy másik útválasztóhoz, csomópont-szerepük lehet.
Furcsa módon, de az átviteli IPv6 csomagokat nem része a profil specifikációknak, és meg van adva az IETF RFC «továbbítása IPv6 csomagokat Bluetooth Low Energy». Ez a dokumentum opredlen másik érdekes pont, nevezetesen, hogy az átviteli IPv6 csomagokat használó 6LoWPAN szabvány - az IPv6 szabványos átjárhatósági át alacsony fogyasztású vezeték nélküli személyes hálózat szabványos IEE 802.15.4.
Nézd meg a képet:
A profil azt írja elő, hogy az IPSS, a GATT és az ATT csak a szolgáltatáskereséshez használható, és a GAP csak az eszköz felfedezésére és kapcsolat létrehozására szolgál.
De vörös színnel kiemelve azt mondja, hogy a csomagok átvitele nem szerepel a profil specifikációjában. Ez lehetővé teszi a programozó számára a csomagátvitel saját végrehajtását.
3. Jobb magánélet és biztonság.
A biztonsági menedzser (SM) egyik feladata a két eszköz párosítása. A párosítás során kulcsokat hoznak létre, amelyeket a kapcsolat titkosítására használnak. A kapcsolási folyamat 3 fázisból áll:
- információcsere a párosítás módjáról;
- rövid távú kulcsok létrehozása (rövid távú kulcs (STK));
- kulcscsere.
A 4.2-es verzióban a második fázist 2 részre osztottuk:
- rövid távú kulcsok létrehozása (Short Term Key (STK)) "LE legacy pairing"
- hosszú távú kulcsok létrehozása (hosszú távú kulcs (LTK)) "LE Secure Connections"
Az első fázist a párosítás másik módja is kiegészítette: "Numerikus összehasonlítás", amely csak a második fázis második változatával működik: "LE Secure Connections".
Ebben az összefüggésben a kriptográfiai biztonsági menedzser eszköztárában lévő 3 meglévő függvény mellett 5 további jelenik meg, és ezek az 5 csak az új "Secure Connections" folyamat végrehajtására szolgál. Ezek a funkciók generálják:
- LTK és MacKey;
- a változók megerősítése;
- hitelesítési ellenőrző változók;
- 6 számjegyű számok a csatlakoztatott eszközök megjelenítéséhez.
Minden funkció 128 bites kulcskal használja az AES-CMAC titkosítási algoritmust.
Tehát, ha a 2. fázisban történő párosítással, a LE legacy párosítási módszerrel 2 kulcsot generált:
- Ideiglenes kulcs (TK): Az STK létrehozásához használt 128 bites ideiglenes kulcs;
- Rövid távú kulcs (STK): 128 bites ideiglenes kulcs a kapcsolat titkosításához
akkor a "LE Secure Connections" 1 kulcs segítségével generálódik:
- Hosszú távú kulcs (LTK): 128 bites kulcs a későbbi kapcsolatok titkosításához.
Ennek az innovációnak az eredménye:
- megakadályozza a nyomkövetést, mert Most a "Numerikus összehasonlítás" miatt lehetőség nyílik arra, hogy ellenőrizzék a készülékkel való kapcsolat lehetőségét.
- Az energiahatékonyság javítása, mert Most nincs szükség további energiára a kulcsok ismételt generálásához minden csatlakozásnál.
- ipari szabvány titkosítás a bizalmas adatok biztosításához.
Furcsa, ahogy hangzik, de a jobb biztonság miatt javulást értünk el az energiahatékonyság terén.
4. Van valami érzés?
Igen, van.
A NORDIC Semiconductor kiadta az "nRF51 IoT SDK" -t, amely magában foglalja a veremeket, könyvtárakat, példákat és API-t az nRF51 sorozatú eszközökhöz. Ezek a következők:
- az nRF51822 és az nRF51422 chipek;
- nRF51 DK;
- nRF51 Dongle;
- nRF51822 EK.
A következő linket töltheti le:
- rövid leírás;
- archiválni a leírt SDK-val;
- a Raspberry Pi rendszermag archívuma, beleértve a forrásokat is.
5. Következtetés.
Köszönöm a figyelmet.