Bluetooth5の補遺
2016 年 6 月に発表された Bluetooth 5 の詳細仕様は、半年後の 12 月 6 日に Core Spec 5.0 として正式に公開されました。しかしニュースリリースの時と違い、IT ニュースは殆どこれを取り上げていません。今回はこの Bluetooth Core Spec 5.0 から、以前「Bluetooth 5 のはなし」で取り上げた新機能...「x2 speed」「x4 range」「x8 data」「Mesh」の実態について解説します。
LE 2Mbps PHY
「x2 speed」として宣伝された 2Mbps モードは、やはり GFSK 変調のままシンボルレートを 2Msym/sec に向上するものでした。PHY 仕様については Vol.6 Part.A 4.4 に、MAC フォーマットは Vol.6 Part.B 2.1 に示されています。1Mbps も 2Mbps もフォーマットはほとんど同じですが、2Mbps モードではプレアンブル時間が同じ 8 μ秒のまま有効データ密度は 2 倍の 16bit に増えています。プレアンブルパターンはどちらも 01010... の繰り返しで、シンボルの反転間隔から 1Mbps/2Mbps の変調モードを判定するようです。ト
LE Coded PHY
ニュースリリース時には言及されていなかった気がするのですが、LE Coded PHY という変調モードも追加されていました(Vol.6 Part.B 2.2)。これはヘッダ部分に 1/8、ペイロード部分に 1/2 または 1/8 の FEC(Forward Error Correction)をかけることにより、伝送速度の低下と引き換えにデータ到達確実性の向上を狙うものです。Bluetooth Classic の BDR にも FEC を伴う DM/DV フレームがありましたが、冗長度は 1/3 ないし 2/3 なので「無いよりマシかも知れない」程度の効果しか期待できませんでした(※註)。今回の FEC は冗長度 1/8 なので、より高いエラー補正効果が狙えるかも知れません。
Coded PHY は常に 1Msym/sec で変調され、それが最大８倍に引き延ばされるのでペイロード長 255 バイト・1/8 FEC 時は 17040μ秒(17.04ミリ秒)という長時間チャネルを占有します。占有時間が延びればノイズ混入の確率も上がりますが、果たして占有時間が８倍に伸びることと、FEC による到達確実性の向上の利害得失がどちら側に転ぶのか、にわかには判断できません
※註：おそらくその中途半端さゆえに、FEC オプションは EDR モードや 4.2 までの LE モードからは撤廃されていました。
TxPower
「x4 Range」と宣伝された距離延伸については、まず推測どおり LE の最大送信出力が 従来の +10dBm(10mW) から Classic Class A 同等の +20dBm(100mW) に引き上げられました(Vol.6 Part.A 3)。また、長距離通信時の伝送遅延に対応するようにタイミングを調整する「Range Delay」仕様が追加されています(Vol.6 Part.B 4.2.3)。これらに加えて前述の LE Coded PHY を併用すれば、FEC のエラー訂正能力によってより遠距離でも通信が成立するかもしれません。
ただし FEC は 1/2 ないし 1/8 の有効データレート低下を伴いますから、以前に書いたように「４倍の距離を２倍の速度で通信できるとは言っていない」ことになります。送信電力が１０倍・通信所要時間が８倍になれば同じ情報量を伝えるために必要な電力は単純計算で８０倍になるわけですから、「同じ消費電力で速度２倍・最大距離４倍」という SIG の売り文句は「速度２倍」でいちど文脈が切れていて、距離４倍時の消費電力や速度については言及していない...「嘘は言っていないが本当のこと全部も言っていない」、ということになるでしょう。
Secondary Advertising
Bluetooth 4.2 までの LE Advertising は 37, 38, 39 の 3 チャネルのみ使用、Advertising PDU は全 7 種類というシンプルな仕様でした。Bluetooth 5 のニュースリリースで「x8 Data size」として宣伝されたアドバータイズ PDU の拡張では、これがだいぶ複雑になります。
まず、従来のアドバータイズチャネル 37～39 は改めて「Primary Advertising Channel」と名付けられ、1Mbps / 最大 37 バイト仕様のまま据え置きです。その代わりデータチャネルでもある 0～36 に「Secondary Advertising Channel」の機能が与えられ、PDU データの 255 バイト拡張はこれらセカンダリチャネルに適用されることになります。ついでに 2Mbps PHY や Coded PHY も使用可能になっています(Vol.1 Part.A 3.3.2.2.2)。要するに「データチャネルをアドバータイズに流用するパスを作った」、ということですね。
セカンダリチャネルへのアドバータイズ送信は２段構えで、まずプライマリチャネル上で「今から何μ秒後にチャネル XX でセカンダリを送信するよ！」という宣告が先行します(Vol.6 Part.B 1.4)。この宣告には ADV_EXT_IND (PDUTYPE=0111) が使用され、そこに含まれる AuxPtr フィールドの Channel Index が「チャネル XX」を、Offset Units / AUX Offset が「今から何μ秒後」を通知します(Vol.6 Part.B 2.3.4.5)。
Advertising PDU には AUX_ で始まる拡張アドバータイズ PDU が 8 種類追加され、全 15 種類に増えました。しかもややこしい事にヘッダの PDU_TYPE (4bit) は従来の Advertising PDU を重複するかたちで割り当てられており(Vol.6 Part.B 2.3.2.1)、例えば TYPE=0011 は ch.37-39 上では「SCAN_REQ」、ch.0-36 上では「AUX_SCAN_REQ」を意味します。両者のフォーマットは全く同じですが、プライマリチャネル上では SCAN_REQ と解釈されて従来の SCAN_RSP が返るのに対し、セカンダリチャネル上では AXU_SCAN_REQ と解釈されて拡張フォーマットの AUX_SCAN_RSP が返ることになります。TYPE=0111 に至っては前述の ADV_EXT_IND(ch.37-39) に加えて AUX_ADV_IND, AUX_SCAN_RSP, AUX_SYNC_IND, AUX_CHAIN_IND(ch.0-36) の 5 種類が一緒くたに割り当てられており、ペイロード中の Extended Header フィールド(Vol.6 Part.B 2.3.4) を読み解いて何であるか判定するようです。
結果的に判断できればフォーマットなんてどうでも良いと言う人もいるでしょうが、同じ PDU_TYPE がチャネルやペイロードによって意味が変わることは、hcidump のような単純なツールでプロトコルを追いかけるときに困難を招きそうです。4bit しかない PDU_TYPE を使い切りたくなかったのでしょうが、Classic の EDR 拡張時に ACL Type を「PTT による切り替え」として BDR と重複して割り当たことで、BDR/EDR の切り替えが煩雑になったことを思い出さずにいられません。
Features Set 拡張
通信相手が LE 2Mbps PHY や LE Coded PHY などの拡張機能に対応しているか否かの判定は、LL Control PDU の FEATURE_REQ / FEATURE/RSP (Vol.6 Part.B 2.4.2.9, 2.4.2.10) で交換される Feature Set ビットによって確認することができます(Vol.6 Part.B Table 4.4)。Bluetooth 4.0 では 1 ビットだけ(LE Encryption)しか無かった Feature Set も 4.1 で 5 ビット、4.2 で 8 ビットに増え、Bluetooth 5 では一気に 17 ビットにまで増えました。ただし PDU_TYPE と違って Feature Set ビットは 8 オクテット = 64bit 幅あるので、当分使い切る心配は要らなさそうです。
Where is Bluetooth Mesh?
ニュースリリース時に華々しく宣伝された「メッシュ対応」についてですが、Bluetooth Core Spec 5.0 を全文検索しても「Mesh」という単語は一回も出てきません。おそらく Core Spec ではなく別の仕様書、あるいはメッシュ・プロファイルとして制定するのでしょう。何だか 4.1/4.2 の時の「IP 対応」の話題を思い出します。この時も IT ニュース等では「次の Bluetooth では IP 対応！」と取り上げられ、しかし Core Spec の何処にも IP の話なんて書かれておらず、別仕様書の IP Support Profile と RFC7688 IPv6 over Bluetooth が揃うまで丸２年近くかかりました。さて Bluetooth Mesh の正式仕様はいつになったら出てくるんでしょうねぇ。
まとめ
実は、Bluetooth の仕様改定については Core Spec の Vol.0 Part.C にまとめられています。今回挙げた機能の他にも Slot Availability Mask とか High Duty Cycle Non-Connectable Advertising も追加されていますが、Bluetooth 5 で目玉とされた機能についてはおおむねこんな所です(項目すらないメッシュを除けば)。
ニュースリリースの時も懐疑的な記事を書きましたが、仕様書を読むとますます「苦しそうだなぁ」と思います。特に Secondary Advertising の仕様はいかにも木に竹を接いだみたいで、こんな回りくどい仕様を使って「37 バイトが 255 バイトに伸びるだけ」というのは何だかなぁという気がします。この２段構えの通信が不特定多数を相手にするフラッドメッシュに適合するかどうかも怪しいところで、Bluetooth Mesh ではセカンダリチャネルは使わず、プライマリの３チャネル・37 バイト制限がそのまま適用されるのかも知れません。
今回もまた懐疑的というか批判的な内容になってしまいました。別に Bluetooth に恨みがある訳でもないのですが、結局ほとんど活用されていない EDR、微妙に使いづらい PAN Profile、すっかり黒歴史化している PAL/AMP、役に立っているのか全然わからない EPC など、かつて何度も「今度の Bluetooth はココがスゴイ！」と報道された新機能の多くが「どうしてこうなった」状態になっている現実を知っているだけに、Bluetooth 5 の新機能を無邪気に「スゴイ！」と喜ぶ気にはなれないのです。
とはいえ Bluetooth 5 の新機能全てが実らなくとも、１つか２つだけでも活用されて Bluetooth 応用の場が広がればいいなとは思っています。このブログを通して何度も書いてきたように、何でもかんでも「唯一無二にして絶対の標準」に押し付けるよりも、必要とされる特性に応じて異なる技術が使い分けられるべきだ、と私は考えていますから。