非公開となったWWDC17の "What's New in Core Bluetooth" セッション

WWDC17のセッション動画は以下で閲覧可能：
https://developer.apple.com/videos/wwdc2017
・・・のように一見見えますが、実は既に一部の動画は非公開となっておりもう見ることができません。そのうちのひとつが "What's New in Core Bluetooth" です。
2024年のいま、2017年のWhat's Newなんてもう必要ないだろう、と思う人もいるかもしれません [1]。
が、Core Bluetoothのようなニッチなフレームワークにとっては、昔のWWDCの発表であれ、それが唯一の一次情報だったりするので、非常に貴重です。
特に、2017年の同セッションは、これまでのWWDCにおいて唯一L2CAPについて言及しているセッションであり、またMTUやEDLにも触れつつ、Core Bluetoothの通信速度に関して事細かに説明してくれているベストプラクティスパートもあり、現在においても非常に有用なセッションです。
スライドは現在でも公開 されており、またトランスクリプトは以下リポジトリにvttファイルとして残されています：
https://github.com/ASCIIwwdc/wwdc-session-transcripts

本記事ではWWDC17の "What's New in Core Bluetooth" セッションの中でも特に重要だと感じた "Getting the Most out of Core Bluetooth"（Core Bluetoothを最大限に活用する方法）パートの内容をまとめます。

なお同セッションの「L2CAP」パートの内容については下記記事に、

また「Best practices」パートの内容については下記記事にまとめました。

以下、文章、画像はWWDCの基本的に同セッションからの引用です。適宜要約したり、順序を並び替えたり、見出しを追加したりしています。また日本語訳だけだと伝わりにくいと思われる部分には原文も載せています。

データ転送が遅い場合の問題

Let's walk through a scenario where we have a lot of data to send from where updating a device.

デバイスを更新する際に送信するデータが大量にある場合のシナリオに沿って説明します。

Today it takes about 3,000 seconds to transfer 1MB of data at about 2.5kbps if we use Write With Response and all defaults.
So this is obviously very slow.
What are the problems?
There's two main problems.

今日、Write With Responseとすべてのデフォルトを使用した場合、約2.5kbpsで1MBのデータを転送するのに約3,000秒かかる。

これは明らかに遅い。

何が問題なのか？

主に2つの問題がある。

Protocol Overhead

The first is all of the protocol overhead in LE.

1つ目は、LEのプロトコル・オーバーヘッドです。

The Bluetooth Specification defines the LE maximum application datalink to be 27 Bytes, but we lose 7 of that because your data has to traverse from the application through GATT, through ATT and through L2CAP, so you lose about 25% of the packet, and in the end the useable data length is only 20 Bytes.

Bluetooth仕様では、LEの最大アプリケーション・データリンクは27バイトと定義されていますが、データはアプリケーションからGATT、ATT、L2CAPを経由する必要があるため、そのうちの7バイトが失われ、パケットの約25%が失われ、最終的に使用可能なデータ長はわずか20バイトとなります。

And in addition, once your data gets through the controller the hardware also adds link layer security and CRC which adds even more time to transmit a packet.
So in order to improve performance, we'll have to performance, we'll have to reduce both the software and hardware overhead.

さらに、データがコントローラを通過すると、ハードウェアはリンク層のセキュリティとCRCを追加するため、パケット送信にさらに時間がかかります。
つまり、パフォーマンスを向上させるためには、ソフトウェアとハードウェアの両方のオーバーヘッドを削減する必要があります。

Write with Response

The second problem is previously in GATT the only way to reliably write is to use Write With Response which take two intervals to complete, one to write and one to wait for the response.

2つ目の問題は、GATTでは以前、確実に書き込むにはWrite With Responseを使うしかなかったことであり、書き込みとレスポンスの待ち時間の2つの間隔を要することです。

So your writes are actually very sparse.
You're not fully utilizing the available bandwidth because, as you know, there's multiple opportunities to transmit per interval and we want to pack as many writes as we can into all of the connection events.

そのため、書き込みは非常にまばらです。
というのも、ご存知の通り、インターバルごとに送信する機会が複数あるため、利用可能な帯域幅を十分に活用できていない。

Write Without Response

So how do we do this?
As Craig mentioned, we've improved Write Without Response.

では、どうすればよいのでしょうか？
Craigが述べたように、我々はWrite Without Responseを改善した。

You can now write and continue to write into Core Bluetooth sets can send holds write without response to false, in which case then your application can wait for a delegate to signal when it's safe to resume writing.
And when you follow the APIs the write will be reliable.
And you can use the Write Without Response to make sure that Core Bluetooth is sufficiently buffered so we can sufficiently buffered so we can use all of the available connection events to send all of your application data.

この場合、アプリケーションは、書き込みを再開しても安全なときにデリゲートがシグナルを送るのを待つことができます。
そしてAPIに従えば、書き込みは信頼できるものになります。
また、Write Without Responseを使用することで、Core Bluetoothが十分にバッファリングされていることを確認することができ、利用可能な接続イベントをすべて使用してアプリケーションのデータをすべて送信することができます。

And in iOS 10, we also enlarged the Connection Event Length so now you have even more room to write using Write For That Response.

さらにiOS 10では、Connection Event Lengthが拡大されたため、Write Without Responseを使用して書き込む余裕がさらに増えました。

And when you pack all of the connection events in all of the interval, your throughput will improve from 2.5 to 37 kbps.

そして、すべての接続イベントをすべてのインターバルに詰め込むと、スループットは2.5kbpsから37kbpsに向上します。

MTUの拡大

And coming back to reducing software protocol overhead, all of the discussion thus far assumes an ATT MTU of 23 Bytes, this is why there are red portion overhead in each viewer packets but we can enlarge the MTU and enlarge the writes to align to the MTU.

This will improve your throughput because L2CAP will now fragment your data for you.

ソフトウェアプロトコルのオーバーヘッドを削減することに戻ると、これまでの議論はすべて、ATT MTUを23バイトと仮定しています。これが、各ビューアパケットに赤色の部分のオーバーヘッドがある理由です。しかし、MTUを拡大し、MTUに合わせるために書き込みを拡大することができます。

これにより、L2CAPがデータをフラグメント化してくれるため、スループットが向上します。

You only have to pay in overhead on the first fragment of your MTU.
The rest of the fragments can be as the full 27 Bytes, so when as the full 27 Bytes, so when you do this your throughput should improve to 48 kbps.

オーバーヘッドを支払う必要があるのは、MTUの最初のフラグメントだけです。
残りのフラグメントは27バイトのフルバイトとすることができますので、27バイトのフルバイトとすると、スループットは48 kbpsに向上するはずです。

And so how do you configure MTU in Core Bluetooth?
If you're running Core Bluetooth to Core Bluetooth, there's nothing much you have to do.

Core BluetoothでMTUを設定するには？
Core Bluetooth同士であれば、特にすることはありません。

We will calculate the MTU for you based on the connection event length and other system configurations but in this example we're from we're updating an accessory.

接続イベントの長さやその他のシステム設定に基づいてMTUを計算しますが、この例ではアクセサリーを更新しています。
したがって、クライアントとサーバー間のトランザクションとしてATT MTU交換を思い出すと、提案された2つの値の最小値は、実際にはATT MTUです。

So if you recall the ATT MTU exchange as a transaction between the client and the server, so the two minimum of the -- the minimum of the two proposed value is actually the ATT MTU, so your accessory should also use a large MTU to take advantage of this more optimized behavior.
And to use a large MTU that's aligned to the -- to use a larger attribute write that is aligned to the MTU, you can use the below interfaces to look at what is the maximum write length what is the maximum write length aligned to the MTU.

そのため、より最適化されたこの動作を利用するために、アクセサリも大きなMTUを使用する必要があります。そして、MTUに合わせた大きなMTUを使用するには、以下のインターフェイスを使用して、MTUに合わせた最大書き込み長を確認することができます。

So thus far we've talked about how to pack as much writes as we can into the intervals and how to utilize -- fully utilize all of the bandwidth available.
We talked about how to reduce overhead, software overhead.
But the fact that LE is 27 Bytes per packet and we have to pay the hardware overhead per packet, this really limits how much further we can improve LE performance using just software.

ここまで、書き込みをできる限り間隔に詰め込む方法と、利用可能なすべての帯域幅をフルに活用する方法について述べてきた。
オーバーヘッドをいかに減らすか、ソフトウェアのオーバーヘッドをいかに減らすかについて話した。
しかし、LEは1パケットあたり27バイトであり、パケットごとにハードウェアのオーバーヘッドを支払わなければならないという事実があるため、ソフトウェアだけでLEのパフォーマンスをこれ以上向上させるには限界があります。

EDL (Extended Data Length)

So we've added extended data length support.
Extended data length is a 4.2 feature that increases the maximum application data length from 27 to 251.

そこで、拡張データ長のサポートを追加しました。
拡張データ長は4.2の機能で、アプリケーションの最大データ長を27から251に増やすものです。

This means that per packet now you can send 10 times the amount of data so you've eliminated all of the hardware overhead and software overhead previously and software overhead previously and we can now use more of the available time to transmit your application data.
And in fact, we can send a full -- an entire maximum GATTs write of 512 Bytes in a single interval using Extended Data Length, and this should be about 3 times the throughput of your normal performance.

つまり、1パケットあたり10倍のデータ量を送信できるようになり、これまでのハードウェア・オーバーヘッドやソフトウェア・オーバーヘッドがすべて解消され、アプリケーション・データの送信に利用可能な時間をより多く使えるようになりました。
実際、拡張データ長を使用すれば、1回のインターバルで最大512バイトのGATTs書き込み全体を送信することができ、これは通常のパフォーマンスの約3倍のスループットになるはずです。

Extended Data Length is the new feature in Bluetooth 4.2.
It extends the maximum application data length from 27 to 251.
It's completely transparent to your application.
If you're running Core Bluetooth to Core Bluetooth we've done everything for you.
We'll negotiate the write data length and MTU appropriate to your hardware configuration, but in this example again we're updating a firmware device so remember you have to also add support for extended data length support for extended data length in the accessory for this to work.
And it has four times the throughput in the same amount of radio time so it's also very power efficient.

拡張データ長はBluetooth 4.2の新機能である。
アプリケーションの最大データ長を27から251に拡張します。
アプリケーションには完全に透過的です。
Core Bluetooth to Core Bluetoothを実行している場合、私たちがすべて行います。
しかし、この例ではファームウェア・デバイスを更新しているため、これを動作させるためには、拡張データ長のサポートをアクセサリに追加する必要があることを覚えておいてください。
また、同じ無線時間で4倍のスループットが得られるため、電力効率も非常に高い。

It's now available on iPhone 7 and Apple Watch Series 2, and the newly announced iPad Pro.
So please try it out and use this as a reference to develop your new Extended Data Length Accessory.

iPhone 7とApple Watch Series 2、そして発表されたばかりのiPad Proで利用できるようになりました。
ぜひお試しいただき、新しい拡張データ長アクセサリーの開発にお役立てください。

L2CAP Connection Oriented Channels

And because we're -- the example is from we're updating a device, this is a good example of where you should use L2CAP Connection Oriented Channel.

この例ではデバイスを更新しているので、L2CAPコネクション・オリエンテッド・チャネルを使うべき良い例だ。

This will eliminate all of the overhead previously in GATT and ATTs, but more importantly it eliminates limitations and restriction in GATT like the maximum attribute size of 512, so we can now write much larger values and use much larger MTU.

これにより、GATTやATTにあったオーバーヘッドがすべてなくなりますが、それ以上に重要なのは、GATTにあった最大アトリビュート・サイズ512といった制限や制約がなくなり、より大きな値を書いたり、より大きなMTUを使ったりできるようになることです。

When we do that the throughput will increase to almost 200 kbps.

そうすると、スループットは200kbps近くまで向上する。

This really shows how powerful Extended Data Length can be if it is not limited by software protocol.

これは、ソフトウェア・プロトコルに制限されなければ、拡張データ長がいかに強力であるかを如実に示している。

As you know, another way to improve performance is to ask for a faster connection interval.
All of the discussion thus far assumes a connection interval of 30 ms, but in Core Bluetooth we made a change to lower the connection interval minimum for iOS to 15 ms, so when your firmware is updating your device you can ask for a parameter update request and set the interval min and max to 15 ms in which we will honor.

ご存知のように、パフォーマンスを向上させるもう1つの方法は、より速い接続間隔を求めることです。
これまでの議論はすべて接続間隔を30ミリ秒と想定していますが、Core BluetoothではiOSの接続間隔の最小値を15ミリ秒に下げる変更を行いました。したがって、ファームウェアがデバイスを更新する際にパラメータ更新リクエストを要求し、間隔の最小値と最大値を15ミリ秒に設定することができます。

And when you do that, your throughput can double to 394, almost 400 kbps.

そうすれば、スループットは2倍の394、ほぼ400kbpsになります。

まとめ

So this is a summary of where we So this is a summary of where we were and where we are now.

これが、私たちがどこにいて、今どこにいるのかについてのまとめです。

We started with Write With Response at 2.5 kbps.
Then we did Write Without Response but writing only once per interval, which only doubles the performance.
But if you packed all of the opportunities to transmit with writes your throughput can improve to 37.
And if you reduce overhead using larger MTU, your performance can go up to 48 kbps.
And we made a major leap forward with Extended Data Length and tripled that which will yield 135 kbps.
And if we eliminate the software limitations using L2CAP plus Extended Data Length, it can improve to almost 200 kbps.
And we increase the -- made the connection interval faster which allows you to transmit more often, then the throughput will improve to 400 kbps.

私たちは Write With Responseで2.5 kbpsから始めました。

次に Write Without Responseを行いましたが、これは一定間隔ごとに1回だけ書き込みを行うもので、パフォーマンスは2倍にしか向上しません。

しかし、送信の機会をすべて書き込みでまとめるようにすれば、スループットは37まで向上します。

さらに、MTUを大きくしてオーバーヘッドを削減すれば、パフォーマンスは48kbpsまで向上します。

そして、拡張データ長を使用することで大幅な進歩を遂げ、135kbpsという結果を得ました。

さらに、L2CAPと拡張データ長を使用してソフトウェアの制限を排除すれば、ほぼ200kbpsまで改善できます。

そして、接続間隔をより高速にすることで、より頻繁にデータを送信できるようになり、スループットは400kbpsに向上します。

So we started with about 3,000 So we started with about 3,000 seconds to download 1 MB of data and we end it with 20 seconds to download 1 MB of data.

そのため、1MBのデータをダウンロードするのに約3,000秒からスタートし、1MBのデータをダウンロードするのに20秒で終了した。

So in summary, please request a shorter connection interval.
The new minimum is 15 MS on iOS if you need it.
Take advantage of all the GATT optimizations we have like Write Without Response.
Use L2CAP Channel for larger transfer.
All of this is free and all in software, and also update your hardware with the latest specification of Bluetooth Specification and Hardware for best performance and best battery life.
Thank you.

まとめると、

接続間隔を短くするようにリクエストしてください。
- iOS での新しい最小値は 15 ミリ秒です。
Write Without Response などの GATT 最適化をすべて活用してください。
より大きな転送には L2CAP チャンネルを使用してください。
これらはすべて無料でソフトウェアのみで利用でき、最高のパフォーマンスとバッテリー寿命を実現するには、Bluetooth 仕様とハードウェアの最新仕様でハードウェアを更新してください。

脚注

おそらくAppleの中の人もそう判断して取り下げたのだと思われる ↩︎

Discussion