Connection Parameter und ihr Einfluss auf die Datenübertragung

Wie schon in unserem vorherigen Artikel „Was ist Slave Latency?“ angesprochen gibt es verschiedene Parameter die die Datenübertragungsrate maßgeblich beeinflussen:

  • connInterval Minimum und Maximum
  • Slave Latency
  • Transmission Window

Connection Interval

Der Connection Interval gibt an wie oft Daten ausgetauscht werden:

„The Link Layer in the Connection State shall only transmit Data Channel PDUs (see Section 2.4) in connection events.” [1]

Wie weit diese Connection Events auseinander liegen wird über den Connection Interval geregelt:

“The start of a connection event is called an anchor point. At the anchor point, a master shall start to transmit a Data Channel PDU to the slave. The start of connection events are spaced regularly with an interval of connInterval and shall not overlap…“ [1]

Somit regelt dieser Parameter wie oft Daten ausgetauscht werden. Er limitiert hierbei direkt die Größe des Transmission Windows, da Connection Events sich nicht gegenseitig überlappen dürfen. Er limitiert beide Seiten, also Slave und Master, gleichermaßen.

Slave Latency

Die Slave Latency ist die Menge an Connection Events die der Slave ignorieren kann. Hierbei ist zu beachten, dass er nicht muss, d.h. wenn der Slave selbst Daten zu versenden hat, wird er seinen Schlaf unterbrechen und dem Connection Event zuhören.

„Slave latency allows a slave to use a reduced number of connection events. The connSlaveLatency parameter defines the number of consecutive connection events that the slave device is not required to listen for the master.“ [1]

Dieser Parameter schränkt den Slave überhaupt nicht ein. Wann immer der Slave Daten hat, kann er diese Senden. Muss der Master nur direkt nach Indications und Notifications des Slave Daten versenden, so ist dieser Parameter auch für den Master keine Einschränkung. Jedoch ist jede Kommunikation die der Master durch einen write_request/read_request anstößt wesentlich langsamer. Nämlich im Durchschnitt (connInterval * slave_latency) / 2 [ms] langsamer. Dies trifft jedoch nicht auf Kommunikationsprozeduren ohne leere Connection Events zu.

Transmission Window

Das Transmission Window ist die Zeit in der Slave und Master, nach einem Anker Punkt, Daten austauschen. Dies beschränkt die Anzahl der Nachrichten in einem Connection Event gesendet werden können. Da Anker Punkte jeweils „Connection Interval“ Millisekunden auseinander sind, muss danach „Connection Interval – Transmission Window“ gewartet werden, bis wieder Daten gesendet werden dürfen.

Abhängigkeiten

Da Connection Intervalle sich nicht überlappen dürfen, muss ein transmit window kleiner sein, also das connInterval:

„The transmitWindowSize shall be a multiple of 1.25 ms in the range of 1.25 ms to the lesser of 10 ms and (connInterval – 1.25 ms).“ [2]

Die Slave Latency darf nicht größer als der Supervision Timeout sein:

„connSlaveLatency shall be an integer in the range of 0 to ((connSupervisionTimeout / (connInterval*2)) – 1). The connSlaveLatency parameter shall also be less than 500.“ [1]

Und natürlich müssen die Connection Intervalle so gewählt werden, dass alles sonstige was die beiden Chips noch zu tun haben in der Zeit zwischen dem Ende eines Transmission Windows und dem Anfang des nächsten Connection Events machbar ist.

Referenzen

[1] BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B], Link Layer Specification, 4.5.1 Connection Events

[2] BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B], Link Layer Specification, 4.5.3 Connection Event Transmit Window
By | 2017-07-17T15:09:40+00:00 März 6th, 2017|Bluetooth Low Energy|