Maximum de la longueur du paquet pour LE Bluetooth?
Je me demandais ce qui était le maximum de la longueur du paquet en Bluetooth Low Energy. Le 20 octets limite si souvent dit, pour exemple ici
"BLE vous permettent de transfert maximale est de 20 octets."
"Il est exact que le BLE spécification ne permet pas d'écrire des opérations de dépasser les 20 octets."
Cependant, la lecture de la Bluetooth de Base de la Spécification, nous pouvons voir que le ATT_MTU valeur est écrit avec 2 octets, ce qui signifie qu'il peut aller jusqu'à 65 535 octets.
Quelle est la vérité derrière tout cela ?
OriginalL'auteur jdoe | 2016-08-12
Vous devez vous connecter pour publier un commentaire.
Spécification est toujours à droite !
En Bluetooth 4.0 BLE a été introduit avec une charge utile maximale de 33 octets (pas y compris l'Accès de l'Adresse et de la CRC champs). Chaque couche de la pile de protocole prend sa coupe:
Avec un TCA demande d'écriture (ou de la notification), 3 octets sont utilisés par la commande type et attribut ID, 20 octets sont disponibles pour les données d'attribut.
À l'ATT niveau, cette limite peut être agrandie de deux façons:
À l'aide de la fragmentation dans le L2CAP niveau:
L2CAP sera divisé ATT Pdu en 27 octets de fragments (23 pour le premier).
Inconvénients:
À l'aide de la longueur du paquet d'extension introduit en Bluetooth 4.2:
Jusqu'à 251 octets au niveau de la radio (255 avec MIC), de sorte 242 octets pour les données d'attribut.
Inconvénients:
Encore nouveau, besoin de support matériel, donc pas mis en œuvre partout (même si l'annonce de BLE 4.2),
Paquet avec plus de temps d'antenne aura plus de chances d'obtenir coincé, donc plus de paquets implique plus de retransmissions.
Si les deux méthodes sont utilisées, L2CAP peut utiliser de plus gros fragments.
Quelle que soit faible niveau de fractionnement de ATT PDU, la valeur de l'Attribut longueur est limitée à 512 par 3.F 3.2.9.
À propos de la valeur de l'Attribut longueur, 3.F 3.2.9 spécifie:
The maximum length of an attribute value shall be 512 octets.
ATT_MTU peut être négocié entre les appareils afin d'atteindre un débit plus élevé, même si, bien sûr, il n'affecte pas le MTU à L2CAP niveau (où MTU est contrôlée par LE paquet d'extension). Cela a été déroutant pour moi comme un c? BLE de nouveaux arrivants, car il n'était pas clair MTU est l'objet de divers articles et comment il est possible de les modifier, même sans BLE 4.2.
Peut-être que je me trompe, mais avec un maximum de 238 n'est pas bonne (w/ longueur de paquet d'extension). La spécification des états que la charge de champ doit être inférieure ou égale à 251 octets de longueur (v4.2 [Vol 6, Partie B], 2.4 Canal de Données PDU), où la charge utile se réfère à une section du Canal de Données de la PDU. Si la charge utile est composée d'un opcode (1 octet), attribut de la poignée (2 octets) et le canal / longueur (4 octets), qui laisse 244 octets pour les données réelles. J'ai été en mesure de confirmer que par l'envoi de certaines données réelles.
Il semble que vous êtes en droit. 251 octets est sans MIC (255), nous obtenons donc à 242 octets pour ATT de données. Édité ma réponse.
OriginalL'auteur Nipo