Když se paket ztratí
BLE má na linkové vrstvě potvrzování a opakování — a dělá to způsobem, který je v celé téhle labce nejcharakterističtější: opakuje se v příští schůzce. Ne hned, ne po mikrosekundách. Až za celý interval.
Z toho plyne, že zpoždění při ztrátě roste po celých intervalech. Při třicetimilisekundovém intervalu a desetiprocentní ztrátovosti dorazí devět zpráv z deseti za 30 ms, jedna za 60, a jedna ze sta za 90.
| ztrátovost | medián | p99 | p99,9 |
|---|---|---|---|
| 1 % | 1 interval | 2 intervaly | 2 intervaly |
| 10 % | 1 interval | 3 intervaly | 4 intervaly |
| 30 % | 1 interval | 4 intervaly | 6 intervalů |
| 50 % | 1–2 intervaly | 7 intervalů | 10 intervalů |
Dvě dobré vlastnosti
Nic se neztratí potichu. Linková vrstva opakuje, dokud to nevyjde nebo dokud nevyprší supervision timeout. Aplikace tedy nemusí řešit ztrátu jednotlivé zprávy — buď dorazí, nebo spadne celé spojení a to se pozná.
Pořadí zůstává. BLE doručuje v pořadí odeslání, takže se nemůže stát, co se běžně stává na IP síti: novější hodnota dorazí dřív než starší.
A jedna špatná
Zpoždění není omezené shora ničím jiným než timeoutem. Při špatném kanálu může zpráva dorazit po deseti intervalech, tedy po třech stech milisekundách — a pro regulaci je to totéž jako by nedorazila. Tohle je přesně ta situace, kdy je zastaralá hodnota horší než žádná.
Řešení je aplikační: posílat data s časovou značkou a na přijímací straně zahodit, co je starší než jeden cyklus. BLE to samo neudělá, protože neví, co je čerstvé.
Jak spojení skutečně spadne: ne kvůli jedné ztrátě, ale když se do supervision timeoutu nepodaří ani jeden pokus. Při intervalu 30 ms a timeoutu 2 s je to 66 pokusů za sebou — což při desetiprocentní ztrátovosti nemá šanci nastat a při padesátiprocentní je to jednou za 10²⁰ pokusů. BLE spojení nepadají kvůli chybovosti; padají, když protistrana zmizí nebo když je timeout nastavený proti nerovnosti z páté kapitoly.