[ble]Connection State

GAPのところがどうも理解できなかったので、もうちょっと調べておこう。

Core_v4.1のp.2537あたりに説明がある。
この辺は、Link Layerのことが書いてあるところだ。

---

4.5 CONNECTION STATE

InitiatorがAdvertiserに対してCONNECT_REQを送信するか、AdvertiserがInitiatorからCONNECT_REQを受信したらConnection Stateになる。
くどい言い回しだが、前者はInitiatorがConnection Stateになるとき、後者はAdvertiserがConnection Stateになるときを指しているのだろう。
並列して書くんじゃなくて、Master目線とSlave目線でそれぞれ分けて書いてあるとよかったのだが。

この段階では、接続は「created」とは認識しているが「established」とは認識していない。
相手から初回のデータチャネルパケットを受信したときのみ、establishedと認識する。
違いがどこにあるかというと、Connection Supervision Timeout値を使うかどうかだ(4.5.2参照)。

masterデバイスは、Connectionイベントのタイミングを制御する。Connectionイベントとはmasterとslaveの同期を取るポイントである。

4.5.1 Connection Events

Connection StateになったLink Layerは、ConnectionイベントとしてData Channel PDUを送信する。
masterとslaveは、Data Channel Indexを4.5.8節のアルゴリズムで決定する。Connectionイベントでは同じData Channel Indexが使われる。最低でも1回はmasterからConnectionイベントが送信される。

(中略)

Connectionイベントのタイミングは、Connectionイベント間隔(connInterval)とSlave Latency(connSlaveLatency)で決定される。

masterはslaveにData Channel PDUを送信し始める(送信しはじめをAnchorポイントと呼ぶ)。
送信間隔は、connInterval。
connIntervalは、7.5msec～4secで、1.25msec刻み。

T_IFSはInternal Frame Spaceで、フレーム間は最低こんだけ空けなさいよ、という時間。
クロック精度とか温度とかの関係で、少し余裕を持たせておかないといかんのよね。
BLEでは、かBluetoothでは、かわからないけど、150usec。

Slave Latencyは、slaveがConnectionイベントの数を軽減するのに使う。
slaveが、masterからのConnectionイベントを連続して何回まで確認しに行かなくてもよいか、という値。
connSlaveLatencyは、0～(connSupervisionTimeout / connInterval) - 1で、500以下。
0だったら、slaveは毎回Anchorポイントを確認することになる。

もしSlave Latency決定後にmasterからパケットを受信できないことがあったら、masterからパケットを受信するまでSlave Latencyは0で動作する。

masterとslaveは16bitのConnectionイベントカウンタ(connEventCounter)を持っていて、最初のConnectionEventで0にする。
Connectionイベントごとにインクリメントして、0xFFFFの次は0x0000に戻る。
このカウンタは、Link Layerが同期を取るのに使う。

4.5.2 Supervision Timeout

相手がいなくなったと認識するまでの時間、でよいのかな。
T_{LLconnSupervision}というタイマで、6 * connInterval経過したら、そう認識するとのこと。

これとは別にconnSupervisionTimeoutという値があり、これはData Packet PDU間のタイムアウト。
connSupervisionTimeoutは100msec～32secの間で、10ms刻み。かつ、(1 + connSlaveLatency) * connInterval * 2以上。

 

connIntervalが1秒で、connSlaveLatencyを4にすると、下限はこんな感じか。