Clever Geek Handbook

Bluetooth v4.2：何が本当に新しく、どのように機能しますか？





こんにちは。



2014年12月3日、Bluetooth SIGはbluetooth仕様バージョン4.2を正式に発表しました。

プレスリリースは、3つの主要な革新を示しています。



プレスリリースの要点： バージョン4.2は、モノのインターネット（IoT）に最適です。

この記事では、これらの3つのポイントがどのように実装されているかを説明します。 歓迎に興味がある人。



以下で説明するものはすべてBLEにのみ適用されます。



1.ユーザーデータの受信と送信の速度を上げます。



BLEの主な欠点は、データレートが低いことです。 どちらの側を見るかは異なりますが、BLEは元々、デバイスに給電するソースのエネルギーを節約するために発明されました。 また、エネルギーを節約するには、断続的に通信して少量のデータを送信する必要があります。 しかし、すべて同じように、インターネット全体は、低速についてのdigりと、それを増加させる可能性、送信データのサイズを増やす可能性についての質問に満ちています。



また、バージョン4.2の登場により、Bluetooth SIGは、送信速度を2.5倍、送信パケットのサイズを10倍に増加したことを発表しました。 彼らはどのようにしてこれを達成しましたか？



この2桁は相互に関連している、つまり、送信されたパケットのサイズが増加したために速度が増加したと、戦闘で言います。



データチャネルのPDU（プロトコルデータユニット）を見てみましょう。



各PDUには16ビットのヘッダーが含まれています。 したがって、バージョン4.2のこのタイトルは、バージョン4.1のタイトルとは異なります。



バージョン4.1のタイトルは次のとおりです。



バージョン4.2のタイトルは次のとおりです。



注：RFU（将来の使用のために予約済み）-この省略形で示されるフィールドは将来の使用のために予約されており、ゼロで埋められています。



ご覧のとおり、ヘッダーの最後の8ビットは異なります。 「長さ」フィールドは、ペイロードの長さとPDUで見つかったMIC（メッセージ整合性チェック）フィールドの合計です（後者が有効な場合）。

バージョン4.1で「長さ」フィールドのサイズが5ビットの場合、バージョン4.2ではこのフィールドのサイズは8ビットです。



ここから、バージョン4.1の「長さ」フィールドに0〜31の範囲の値、およびバージョン4.2の0〜255の範囲の値を含めることが簡単に計算できます。最大値からMICフィールド長（4オクテット）を引くと、ペイロードは、バージョン4.1および4.2の場合、それぞれ27オクテットおよび251オクテットです。 実際、最大データ量はさらに少なくなります。 ペイロードには、L2CAP（4オクテット）およびATT（3オクテット）サービスデータもありますが、これは考慮しません。



したがって、送信されるユーザーデータのサイズは約10倍に増加しました。 なんらかの理由で10倍ではなく2.5倍にしか増加しなかった速度については、200バイトの配信を保証することはもう少し難しいため、すべてがデータの保証配信にも依存するため、比例した増加について話すことはできません20より。



2.インターネットに接続する機能。



おそらく最も興味深いイノベーションは、Bluetooth SIGがバージョン4.2でモノのインターネット（IoT）を改善すると発表したため、まさにこの機能のおかげです。



バージョン4.1に戻ると、「LEクレジットベースのフロー制御制御モード」がL2CAPに登場しました。 このモードでは、いわゆるを使用してデータのフローを制御できます。 ローンベースのスキーム。 このスキームの特徴は、送信されたデータの数を示すために信号パケットを使用せず、送信のために一定量のデータを別のデバイスからローンで要求し、それによって送信プロセスを高速化することです。 同時に、受信側はフレームを受信するたびにフレームカウンターを減らし、最後のフレームに到達すると接続を切断する可能性があります。



L2CAPコマンドのリストに3つの新しいコードが登場しました。

-LEクレジットベースの接続要求-ローンスキームに従った接続の要求。

-LEクレジットベースの接続応答-ローンスキームに従った接続への応答。

-LE Flow Control Credit-追加のLEフレームを受信する可能性に関するメッセージ。



パッケージ「LE Credit Based Connection request」



デバイスがL2CAPレベルで送信できるLEフレームの数を示す2オクテットの「初期クレジット」フィールドがあります。



応答パッケージ「LE Credit Based Connection response」



同じフィールドは、別のデバイスが送信できるLEフレームの数を示し、接続要求の結果が[結果]フィールドに示されます。 値0x0000は成功を示し、他の値はエラーを示します。 特に、値0x0004は、リソース不足による接続障害を示します。



したがって、すでにバージョン4.1では、L2CAPレベルで大量のデータを転送することが可能になりました。

そして現在、バージョン4.2のリリースとほぼ同時に公開されています。



L2CAPレベルの主なプロファイル要件は、バージョン4.1で導入された「LE Credit Based Connection」です。これにより、MTU> = 1280オクテットのパケットを転送できるようになります（図のヒントが明確であることを願っています）。



このプロファイルは、次の役割を定義します。

-ルーター（ルーター）の役割-IPv6パケットをルーティングできるデバイスに使用。

-ノードの役割-IPv6パケットのみを送受信できるデバイスに使用。 サービス発見機能と、ルーターがこのデバイスを発見できるようにするIPSSサービスがあります。



別のルーターに接続する必要があるルーターの役割を持つデバイスには、ホストの役割がある場合があります。



奇妙なことに、IPv6パケット送信はプロファイル仕様の一部ではなく、Bluetooth Low Energyを介したIPv6パケットの IETF RFC Transmissionで指定されています 。 このドキュメントでは、IPv6パケットを送信する際に6LoWPAN標準が使用されます。これは、IEE 802.15.4標準の低電力無線パーソナルネットワークでのIPv6通信の標準です。



写真を見てください：



このプロファイルでは、IPSS、GATT、およびATTはサービスの検出にのみ使用され、GAPはデバイスの検出と接続の確立にのみ使用されることを定義しています。



しかし、赤で強調表示されているのは、パケットの転送がプロファイルの仕様に含まれていないことだけです。 これにより、プログラマはパケット転送の実装を作成できます。



3.プライバシーとセキュリティの改善。



セキュリティマネージャー（シークリティマネージャー）（SM）の責任の1つは、2つのデバイスをペアにすることです。 ペアリング中に、通信の暗号化に使用されるキーが作成されます。 ペアリングプロセスは3つのフェーズで構成されます。



バージョン4.2では、第2フェーズは2つの部分に分割されました。



そして、第1フェーズは別のペアリング方法によって追加されました。「数値比較」は、第2フェーズの第2バージョンである「LE Secure Connections」でのみ機能します。



これに関して、3つの既存の機能に加えて、セキュリティマネージャーの暗号化ツールボックスにはさらに5つが登場し、これら5つは新しいLEセキュア接続ペアリングプロセスのサービスにのみ使用されます。 これらの関数は以下を生成します。

すべての機能は、128ビットキーでAES-CMAC暗号化アルゴリズムを使用します。



そのため、「LE legacy pairing」メソッドによる第2フェーズのペアリング中に2つのキーが生成された場合：



次に、LE Secure Connectionsメソッドによって1つのキーが生成されます。



私たちが受け取ったこの革新の結果：



奇妙なことですが、セキュリティが向上したため、エネルギー効率が改善されました。



4.感じる機会はすでにありますか？



はい、あります。

NORDIC Semiconductorは、nRF51シリーズデバイスのスタック、ライブラリ、サンプル、APIを含む「nRF51 IoT SDK」をリリースしました。 これらには以下が含まれます。



リンクからダウンロードできます：



5.結論。



もちろん、個人的に最も期待されていたのは、送信速度と送信データのパケットサイズの増加でした。

2015年の第1四半期に、バージョン4.2をサポートする最初のチップが登場し、モバイルプラットフォームが更新されます。これにより、モノのインターネットの世界に新しい機能が追加されます。



ご清聴ありがとうございました。


More articles:


All Articles